[HN Gopher] Apple proposes adding "model" element to HTML that d...
___________________________________________________________________
Apple proposes adding "model" element to HTML that displays 3D
content
Author : Jyaif
Score : 215 points
Date : 2021-08-30 09:23 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| neilv wrote:
| I don't understand why a 3D geometry model would best be called
| simply "model" in the context of HTML.
|
| The term "model" is a pretty generic term that's very relevant to
| HTML, already used heavily in Web frameworks, etc.
| rjsw wrote:
| It matches the MIME Type for that kind of thing.
| amelius wrote:
| Because "3dmodel" is not a valid identifier?
| [deleted]
| nickpow43 wrote:
| <geometry> would be nice.
| reportgunner wrote:
| yeah just call it <threedee>
| silvestrov wrote:
| At least they could use a proper name instead of the generic
| "model", something like "object3d".
| edflsafoiewq wrote:
| They could just use <object>.
| jpm48 wrote:
| Interesting they show support for USD(Z) in the example. USD will
| be the standard for most VFX houses and make tooling for various
| web based systems so much easier.
| moron4hire wrote:
| We have a 3D model format for the web in glTF. This is Apple
| having Not Invented Here Syndrome again. USD was developed at
| Pixar, of which Steve Jobs was the founding investor. Apple is
| the only one who wants USDZ on the Web. Everyone else is
| already using glTF.
| ohgodplsno wrote:
| USD is widely used in all industrites, from video games to
| archviz to 3D rendering. If anything, glTF is the niche
| format.
| Bigpet wrote:
| USD, glTF and COLLADA are all "widely used" in some parts.
| I would like to see some data that USD is more popular than
| the other ones.
| moron4hire wrote:
| GLTF, especially the binary format, is specifically design
| for transmission over the web. Wavefront is uncompressed
| text, Collada is even worse because it's extremely verbose
| XML. I don't know _a lot_ about USDZ, but what I do know is
| that it 's overkill for the web (graphics features that are
| mostly too costly to do in WebGL, additional scene
| description data like audio tracks, etc), while also
| lacking specific features that GLTF has that are aimed at
| the web, like streaming, progressive download of texture
| data.
| midnightclubbed wrote:
| Nvidia are also leaning very hard into USD with their meta-
| verse project. In that case USD matches requirements
| perfectly.
|
| glTF 2.0 is widely supported although the quality of that
| support is variable. The spec is fairly large and every tool
| that exports glTF does so in a subtly different way.
|
| For instance Blender adds a rotation transform node before
| every mesh to convert from Y-up (Blender) to Z-up (glTF).
| Animations run in Y-up space and target the node before that
| final rotation node. The BabylonJs exporter for 3dsMax
| converts its meshes and animations to z-up as part of the
| export process. Many glTF loader implementations get tripped
| up on this (failing to support more than one model mesh or
| failing to respect the full transform hierarchy or failing to
| support animations). There are similar complexities and
| support issues around vertex data formats, buffer layouts,
| punctual lights etc
|
| My limited reading of the USD format is that it has an even
| wider specification. My concern is that browser support will
| splinter even worse than it would with glTF. The' model'
| proposal doesn't dig into what USD nodes will and won't be
| supported and exactly how the data is expected to be
| rendered.
| moron4hire wrote:
| Blender is Z-up and glTF is Y-up, but regardless, this is a
| long standing issue of Blender. These problems exist for
| all of the model export formats coming out of Blender. How
| is that glTF's fault?
| stefan_ wrote:
| Even Windows 10 now has a glTF viewer, as I recently learned.
| tpmx wrote:
| Where is the format specification?
|
| https://graphics.pixar.com/usd/docs/
|
| The closest thing I can find there is the glossary and the C++
| doxygen api docs.
| jpm48 wrote:
| It's a schema specification with various plugins. I guess it
| will mainly be about the geo specification for models (and
| perhaps ignore the shaders etc). Documentation is hard to
| come by, you basically have to look at the source / examples.
| da_big_ghey wrote:
| gltf2 is a good format, though is complex, it is open standard
| and has good support. probably should be the choice not
| wavefront or usdz.
| jchw wrote:
| I'm annoyed at the realization that Safari will likely support
| this before it supports WebM or Ogg.
| doctornoble wrote:
| WebM support has been added to Safari 15
| jchw wrote:
| For macOS, where you can _also_ install Chrome or Firefox if
| you wanted to. Not iOS. Not even in beta.
| ihuman wrote:
| iOS 15 will at least add support for "WebM Web Audio" and
| "WebM MSE parser"
| robertoandred wrote:
| Just because Google pushes their pet format doesn't mean the
| industry needs to be their lapdogs.
| jchw wrote:
| Please explain to me how Ogg Vorbis and Ogg Opus are still
| not supported, then. Please tell me why Apple has no answer
| for a patent-unencumbered format that replaces it. Better
| yet, please explain why Google's "pet formats" are evil, bad,
| or even just not good. I'm tired of hearing this argument. So
| basically Google made WebM, so we can never have open formats
| in browsers? How is this really the answer that's better for
| the web ecosystem?
|
| Not supporting WebP had some merit, considering there were
| other answers, but WebM basically doesn't have any better
| alternatives. Even iPhones have the necessary hardware to
| decode VP8 and VP9. Why does Firefox support WebM if it's so
| bad for the web? Why is Apple even part of the AV1 alliance
| without releasing software that supports it?
|
| I don't like Apple getting a free pass on positive intent
| because it's not Google. Whether its codecs (which Apple
| holds both MPEG-4 _and_ HEVC patents,) or WebGPU shaders
| (nobody else wanted WSL, but Apple forced it on us,
| apparently because of SPIR-V IP conflicts,) people seemingly
| make up excuses for why it's OK that they lag on standards
| that nobody else seems to have an issue with. It's beyond
| frustrating. It's infuriating. As a web developer, it's a
| bigger problem to me than anything Google Chrome does, and
| trust me, that's saying a lot.
| Benjamin_Dobell wrote:
| This doesn't really seem like the right abstraction. 3D models
| are inherently interactive.
|
| There could be some value in supporting _3D video_ , where
| interaction is inherently limited to 3 degrees of freedom. There
| may even be value to the "videos" being represented as 3D scenes
| with animation i.e. rendered on the device.
|
| However, "models" are something you need to interact with. To
| achieve an even remotely acceptable level of UX those
| interactions absolutely need to be custom tailored for the
| content.
|
| Let's say you want to display a 3D building interior. If you're
| going to allow _any_ form of free camera movement, you need to
| define how that logic works.
|
| Do we want first person walk-through? If so, you need collision
| detection. For simplicity, let's assume you can walk through
| walls. However, at the very least you'll want to walk on the
| floor. What about split levels and stairs?
|
| No. That sounds too hard. We'll rule out walk-through. We've now
| got a floating camera, and it'll happily pass through any
| geometry.
|
| Now, should the camera orbit around a point, or is a first-person
| flying camera more appropriate?
|
| Wait, how fast should the camera even move when you indicate you
| wish to move forward? Okay, let's make that configurable.
|
| What if you have two points of interest and a large gap in
| between? How do we get from one area to other? Should the camera
| travel faster in this area? Should there be some standard
| mechanism to jump to another location in the scene?
|
| Hmm, too hard. Let's ignore that problem for now.
|
| Should there be constraints with respect to how far you can zoom
| in and out? I guess we could define that in the file somehow.
|
| Okay.
|
| Animation tracks. They were mentioned. Do they all auto-play? Is
| that going to be performant? What if we want to trigger animation
| tracks based on camera location or some other event?
|
| We'll need, like a DOM, I guess?
|
| > _while we are not proposing a DOM for the data at the moment,
| we expect to in the future_
|
| Ah, right. Well. Let's assume in the future there's a DOM.
|
| Wait? How do we interact with the DOM? JavaScript somewhere?
| Where are we collecting user events from to drive this
| interaction? Can we display UIs within the 3D scene and receive
| events? How do we build those UIs?
|
| This snowballs _real_ fast. The solution you 're going to end up
| with is WebGL/WebGPU. Anything less than that is far too
| restrictive and going to make for a terrible user experience.
| ybahubali2018 wrote:
| This functionality resembles Adobe Flash
| AlexAltea wrote:
| Dismissing Apple's <model> HTML element proposal because
| WebGL/WebGPU on <canvas> already "solve" the problem feels short-
| sighted...
|
| Under that logic, shouldn't we replace <img> and <video> elements
| with WASM modules for ffmpeg/libjpeg/libpng rendering into a
| <canvas> too?
|
| Or hey, maybe we could drop HTML altogether and just render all
| content from WebAssembly straight into the <body>?
| smoldesu wrote:
| > Under that logic, shouldn't we replace <img> and <video>
| elements with WASM modules for ffmpeg/libjpeg/libpng rendering
| into a <canvas> too?
|
| If we're going to town, we may as well go in a Lincoln. Maybe
| I've just been working in Rust too much recently, but this was
| my exact thought too upon reading this.
| lostmsu wrote:
| Hooray, WPF 3D [0] and VRML [1] are back in the "modern" form!
|
| [0] https://docs.microsoft.com/en-
| us/dotnet/desktop/wpf/graphics...
|
| [1] https://en.wikipedia.org/wiki/VRML
| mortenlarsen wrote:
| Didn't have this before? VRML (Virtual Reality Modeling Language)
| in the 90's.
|
| I seem to recall using it on my SGI O2 with Irix and Netscape.
| raxxorrax wrote:
| > Privacy considerations
|
| Rendered <model> data is not exposed to / extractable by the page
| in this proposal, so no tainting is required. We do expect this
| would require extensions to Fetch (a new destination type),
| Content Security Policy (a new policy directive), and likely a
| few others.
|
| I do buy 3d model data occasionally (hobby, not for professional
| uses). I think most stores obfustcate the data somehow although I
| never took a look at it in detail. If you wanted, you probably
| could easily extract the model from the preview.
|
| I still think this is a very bad proposal. Why compare something
| with an image and then disallow it to be treated like other
| ressources? This is typically bad corporate influence on the web.
|
| I think we should go the other way. Remove DRM components from
| browsers again. Netflix not available anymore? They will either
| adapt or not be available. Their loss would probably be more
| significant.
| Telemakhos wrote:
| As I understand it, this is not so much about DRM as it is
| about privacy. The new model tag allows the browser to sandbox
| the display of a 3d object without reporting information back
| to the web page/server. This way, the browser can use camera
| data to track the user eye position relative to the device for
| parallax or to show what is behind the device to accomplish the
| effect known as "augmented reality." In other words, Apple
| wants developers to be able to deploy augmented reality
| experiences on the web without giving them access to the user's
| camera, which is a privacy issue.
| dheera wrote:
| Hmmm I wonder if this would open more side channel attacks to
| extract information about the user without even going through
| a permissions dialog.
| snet0 wrote:
| My understanding is basically that DRM is the technology that
| permits the existence of Netflix and similar. Perhaps I just
| lack a strength of principle, but I don't see why you'd remove
| one of the most-enjoyed aspects of the internet for the sake of
| uh... some kind of privacy-adjacent something?
| dangerface wrote:
| Netflix make money from their subscription service not DRM. I
| can easily torrent anything I watch on netflix but I watch it
| on netflix because its easier. Thats why I pay for netflix
| its not because their DRM prevents me from pirating anything.
| snet0 wrote:
| Sure, but do you not think Netflix would have issues
| acquiring content if users could right click->save
| everything they viewed?
| tehbeard wrote:
| We got to an ok compromise of video tags and native browser
| support, with DRM extension for corporate needs/reqs... Is it
| the best? No. Could it worse, definitely.
|
| But without it youd need a Netflix app on your PC... And what
| safeguards does that have from hoovering my pc usage up for
| sale or marketing? Atleast Netflix only gets MY Netflix
| consumption for their metrics and ML, and isn't cross
| referencing the games I play or other things I'm doing at the
| same time.
| snet0 wrote:
| In addition to the privacy concerns with native
| applications, they're almost always insecure. One thing
| that is nice about modern browsers is that (despite
| Safari's leisurely update cycle) they are actually
| relatively secure, as far as software goes. Threats to the
| average user of Chrome are things like phishing, rather
| than RCE, and tab isolation keeps things from escalating
| out of control.
|
| Contrast that to the now ubiquitous conferencing software
| solutions, and it seems like every day there's some zero-
| day RCE vulnerability or other spooky exploit.
|
| If we needed to install and run a dozen different closed-
| source executables from BigCorp et al., I predict that we'd
| very soon go back to security dark-ages.
| frostburg wrote:
| Isn't everything on Netflix ripped as soon as it is
| available? What is the DRM doing? Compliance?
| gruez wrote:
| >I still think this is a very bad proposal. Why compare
| something with an image and then disallow it to be treated like
| other ressources? This is typically bad corporate influence on
| the web.
|
| Because webgl fingerprinting. Also, I'm not sure why you think
| not being able to extract the data using javascript is "bad
| corporate influence on the web" or" DRM". you can still do
| whatever you want. The models are freely available for _you_
| just not the page.
| BiteCode_dev wrote:
| You, the dev. Not you the client, hence the user. It's closed
| software by design, and we all have seen where it leads to.
| gruez wrote:
| >You, the dev.
|
| As per the parent comment, it's not exposed to the
| javascript running on the page, which is arguably the "dev"
| in this case.
|
| >Not you the client, hence the user.
|
| I fail to see how it being exposed to the javascript
| running on the page or not makes a meaningful difference to
| the user. Are we expecting the average user to interact
| with the page via the developer console or something?
|
| >and we all have seen where it leads to.
|
| The proposal doesn't have any DRM element at all. At worse
| you can just inspect network traffic to download the model
| file to disk and open it in whatever app you want.
| BiteCode_dev wrote:
| > I fail to see how it being exposed to the javascript
| running on the page or not makes a meaningful difference
| to the user. Are we expecting the average user to
| interact with the page via the developer console or
| something?
|
| No, but I'm expecting the average user to be able to
| enjoy an open ecosystem. Such as bookmarklet, addons,
| client side widgets, electron apps, WASM plugins, and all
| the wonderful things we can't yet think of now.
|
| Instead, we will have one more walled garden.
|
| And just like that, piece by piece, the next step in the
| IT revolution will be more and more close. Because that's
| the plan, that's what they want. Something the computer
| runs, but has no control over.
| gruez wrote:
| >No, but I'm expecting the average user to be able to
| enjoy an open ecosystem. Such as bookmarklet, addons,
| client side widgets, electron apps, WASM plugins, and all
| the wonderful things we can't yet think of now.
|
| But there's still webgl and <canvas>. I'm failing to see
| what type of use cases we're missing out on here, because
| javascript access is missing.
| imwillofficial wrote:
| Closed software? You mean being used by every person on
| earth every day of their lives?
| BiteCode_dev wrote:
| People also consume refined sugar, alcohol, saturated fat
| and cigarettes regularly.
|
| Just because something is common doesn't mean it's good
| for you.
|
| I'm not against closed software mind you, I'm using some
| myself, but the web as a platform has reached this
| amazing stage because it's been built on openness. And
| now the very same companies that became rich thanks to
| this openness want to close it to get all the benefits
| for themself.
| nynx wrote:
| I think this is a great idea. It'd let people pull the model that
| the page is using pretty easily, which would be great.
| rightisleft wrote:
| I'll just leave this here: http://iswebrtcreadyyet.com/
| sfink wrote:
| Counterproposal: let's add a new element <visible-complicated-
| stuff>. It accepts <source> children. You can do <visible-
| complicated-stuff interactive> and it does... interactive stuff
| of some sort, but nothing that could be visible from JS because
| that would leak privacy info, so really it would get direct
| mouse/keyboard/camera input and do something with it according to
| the vast list of standardized possibilities. Which would be
| length 1, because any more than that would be an interoperability
| nightmare. We'll give it the MIME type
| "application/stuff+interactive".
|
| The source data would be interpreted according to its own vast
| list of standardized possibilities, which realistically would
| have a 3D model format subset of size zero because 3D formats are
| so diverse and cater to such different needs that etching one in
| stone for standardization is kinda silly. But we can pretend
| it'll be size 1. In which case the subtly differing
| implementations of lighting, texturing, potentially rigging, etc.
| will make it nonportable for the next decade or so, at which time
| we'll have a common-denominator format a decade out of date. But
| at least we called it "stuff" instead of "model" because then you
| couldn't put a scene into it and $DEITY help you if you wanted to
| animate anything.
|
| Ok, it's not a _great_ counterproposal. But it doesn 't feel like
| it's inferior to the proposed <model> in any way, and has the
| advantage of being slightly more honest with its naming.
|
| The only way I could take this proposal seriously is if it set
| out up-front to define an extremely limited subset of
| capabilities that are broadly useful. Something like <triangles>
| with a 'camera' attribute and <lighting> children or something.
| _Then_ you could evaluate various file formats for suitability.
| But I just don 't see any simplistic subset that would make any
| two groups of people happy. Everyone needs a tiny bit of
| additional capability for their use case. This is not a
| subsettable problem.
| kelvin0 wrote:
| Blobs. Enjoy.
|
| https://developer.mozilla.org/en-US/docs/Web/API/Blob
| epaulson wrote:
| I thought this Twitter thread by one of the Google WebGL folks
| and a response from an Apple Webkit engineer had some good
| perspectives:
|
| https://twitter.com/Tojiro/status/1432382837735374855
| mkl95 wrote:
| It would be a great idea if WebGPU wasn't a thing. Imo Apple and
| big corp should double down on their WebGPU support instead of
| pitching their own ideas. And if they want to support something
| that is production ready, WebGL2 has been out there for a while.
| pjmlp wrote:
| Exactly, https://modelviewer.dev/
| twic wrote:
| Why not just use the existing object element? There is a section
| "Why add a new element?", but it only talks about canvas!
| Closi wrote:
| They also said the following:
|
| > It would be possible to reuse one of the generic embedding
| elements, such as <embed> or <object>, for this purpose.
| However, we think that 3D content should behave like other
| media types.
|
| I think their argument is that although it is semantically
| possible to use object, they think this would be clearer for
| the future.
| satori99 wrote:
| This could be implemented right now using native browser APIs
| (custom elements w/ closed shadow roots & WebGL), on a per site
| basis.
|
| Seems a bit pointless really.
| afandian wrote:
| What is old is new. https://en.wikipedia.org/wiki/VRML
| moron4hire wrote:
| Are you the one who posts this link on anything 3D-in-the-
| browser posted here? If you knew anything about either, you'd
| know they are completely different things.
|
| VRML was more like 3D, inline SVG, before SVG in the browser
| was a thing. It was markup in the page. And it was meant to be
| scriptable and interactive. This is none of those things.
| afandian wrote:
| No I'm not.
| zamalek wrote:
| There's an existing standard that they could have collaborated
| on. https://en.wikipedia.org/wiki/X3D
|
| > Striving to become the 3D standard for the Web, X3D is designed
| to be as integrated into HTML5 pages as other XML standards such
| as MathML and SVG. X3DOM is a proposed syntax model and its
| implementation as a script library that demonstrates how this
| integration can be achieved without a browser plugin, using only
| WebGL and JavaScript.
|
| Apple is demonstrating a pretty bad case of "not invented here"
| syndrome.
| bastawhiz wrote:
| Apple isn't doing anything that's incompatible with X3D. In
| fact, they didn't even specify which kinds of models they would
| accept (there's a `type` on the <source> elements). You could
| easily point one of those at an X3D file.
|
| Sure, you could put an <X3D> tag into a HTML document, but
| there's no `<img>` equivalent (like you can use with SVG) to
| load that content from another URI. When dealing with extremely
| large (byte-wise) or complex shapes, having the option to load
| that data separately (or in a more efficient binary format) is
| obviously desirable.
| zamalek wrote:
| Re-iterating the quote from my comment:
|
| > X3D is designed to be as integrated into HTML5 pages as
| other XML standards such as MathML and SVG. X3DOM[...]
| bastawhiz wrote:
| And as I said, there's exactly nothing that makes the
| proposed tag incompatible with that idea. It's just another
| way of linking to that file. Inlining content is not
| universally desirable.
| zamalek wrote:
| Yes, there is. X3D can be embedded into HTML exactly like
| SVG, per the quoted text and this example:
| https://doc.x3dom.org/tutorials/basics/hello/index.html
| dragonwriter wrote:
| > Sure, you could put an <X3D> tag into a HTML document, but
| there's no `<img>` equivalent (like you can use with SVG) to
| load that content from another URI.
|
| Yes, there is, the HTML <object> tag.
|
| https://www.web3d.org/x3d/content/HtmlObjectTagForX3d.html
| shawnz wrote:
| <object> is not a satisfactory equivalent for this <model>
| tag any more than it's a satisfactory equivalent for the
| <img> tag itself. <object> is semantically a superset of
| both.
| dragonwriter wrote:
| > <object> is not a satisfactory equivalent for this
| <model> tag any more than it's a satisfactory equivalent
| for the <img> tag itself.
|
| The main reason for having both <img> and <object> is
| that <img> existed first, and removing tags is almost
| always a bad idea because it brraks existing sites.
|
| > <object> is semantically a superset of both.
|
| Yes, that's why given its existence, introducing new tags
| that offer a strict subset of its utility is unnecessary.
| shawnz wrote:
| I think it's pretty clear that that is NOT the reason why
| <img> still exists. Otherwise, why not just discourage
| its use in favour of <object> while still retaining it
| for compatibility? But actually the opposite is true,
| <img> is encouraged because it is more semantically
| descriptive and provides image-specific features that
| couldn't reasonably be added to <object>.
|
| If this line of thinking actually matched what the W3C
| believed, then how can you explain the addition of ANY of
| the new tags, for example, in the HTML 5 specification,
| since we already have the most general cases covered with
| things like <object> and <div>? Following this to its
| logical conclusion, why not deprecate EVERY tag except
| those? Why have tags at all?
| bastawhiz wrote:
| The object tag is problematic because it has a single
| interface for _every supported content type_. Want to
| expose functionality? Can 't, unless it's a param that is
| passed as a string. Having a dedicated element type enables
| it to be used in many ways (like drawing images to a
| canvas) that an object tag does not support.
|
| It's also hardly a case of NIH to update a spec with a more
| specific element than another one _in the same spec_. We
| 've done this numerous times in the last decade. The object
| tag isn't an X3D concept.
| dragonwriter wrote:
| > The object tag is problematic because it has a single
| interface for every supported content type. Want to
| expose functionality? Can't, unless it's a param that is
| passed as a string.
|
| On a markup level, that's true of any tag.
|
| On a functional level, it's not true of <object>, as the
| tag expects supported functionality to be defined
| separately for every type.
|
| > Having a dedicated element type enables it to be used
| in many ways (like drawing images to a canvas) that an
| object tag does not support.
|
| There'd nothing preventing the handler for a media type
| from doing that.
| shawnz wrote:
| > Apple is demonstrating a pretty bad case of "not invented
| here" syndrome.
|
| I don't think that's the case here at all. Apple's proposal
| solves a completely different problem, which is to embed
| arbitrary model formats on the page. X3D is just one possible
| format and without something like Apple's proposal in
| combination, it could _only_ be used inline, which may not
| always be preferred.
| new_guy wrote:
| Apple needs to concentrate on bringing Safari upto spec before
| suggesting more half-assed ideas.
| Ajedi32 wrote:
| My initial reaction to this was "just use WebGL", but they've
| made a pretty compelling case as to why that's not ideal:
|
| > Consider a browser or web-view being displayed in Augmented
| Reality. The developer wants to show a 3D model in the page. In
| order for the model to look accurate, it must be rendered from
| the viewpoint of the user - otherwise it is a flat rendering of a
| three-dimensional image with incorrect perspective.
|
| > A solution to this would be to allow the Web page, in
| particular the WebGL showing the 3D model, to render from the
| perspective of the user. This would involve granting too much
| private information to the page, possibly including the camera
| feed, some scene understanding, and very accurate position data
| on the user. It should not be a requirement that every Web page
| has to request permission to show a 3D model in this manner. The
| user should not have to provide access to this sensitive
| information to have the experience.
|
| > Furthermore, there is more information needed to produce a
| realistic rendering, such as the ability to cast and receive
| shadows and reflections from other content in the scene, that
| might not be on the same Web page.
|
| From that perspective, having the rendering handled by the
| browser seems like a smart idea.
| corentin88 wrote:
| > Consider a browser or web-view being displayed in Augmented
| Reality
|
| Feels like Apple is working on something that needs this.
| wlesieutre wrote:
| Related history, <canvas> came about from Apple's Dashboard
| in 10.4
| corentin88 wrote:
| Oh interesting. Do you have more details about that?
|
| Edit: it's on the first paragraphs of the MDN page about
| <canvas> [1]:
|
| > First introduced in WebKit by Apple for the OS X
| Dashboard, <canvas> has since been implemented in browsers.
| Today, all major browsers support it.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/API/Canvas_API/...
| jayd16 wrote:
| I don't understand why passing a new view matrix to webGL is
| such a security risk or why that needs to be shared with he
| site owner.
|
| I also think a window with a dynamic view matrix would make
| more sense in certain cases. Some techniques work when rendered
| to a surface that would not work in VR, ie screen space
| effects.
| skybrian wrote:
| It's not exactly eye tracking, but you know some advertisers
| are going to use it to make ads that turn to point directly
| at you.
|
| But I'm not sure the proposed tag is a good idea either. I
| have not used VR but I think it might be a good thing if web
| browsers in VR stay flat and can't take over the space in
| front or behind them?
| Ajedi32 wrote:
| > it might be a good thing if web browsers in VR stay flat
| and can't take over the space in front or behind them
|
| IMO the preferred implementation would be for the <model>
| tag to be a window into a 3d space "behind" the browser
| that's only visible if you look through that window. Maybe
| a small area in front of the window would also be
| acceptable. You wouldn't want it taking over space outside
| its designated area though without either going
| "fullscreen" or getting some other form of permission.
| stefan_ wrote:
| WebGL exists, why do we need a budget restricted version of a
| model viewer in the browser? None of the motivations are at all
| convincing. Should browsers now be obliged to integrate with VR
| headsets?
| adamsvystun wrote:
| Not exactly the same, but a similar question is then: "Canvas
| exists, why do we need an image element?"
| atom_arranger wrote:
| I see a future where with some changes made to improve A11Y
| webpages are entirely rendered in WebGL.
| DocTomoe wrote:
| Also, both VRML and Web3D do exist.
| laumars wrote:
| Not used Web3D but VRML is a dead language. Which is a pity
| because VRML was extremely fun to code in. Sadly it was a
| victim of being release too early (even VRML2 was out before
| most people 3D accelerators).
| zozbot234 wrote:
| VRML is not so much dead as subsumed by X3D, and any newly-
| proposed standard for 3D models on the Web should at least
| have feature parity with that.
| tenaciousDaniel wrote:
| Not only WebGL, but WebGPU is also in the works. I simply don't
| understand this proposal.
| imwillofficial wrote:
| When I don't understand something, I ask lots of questions.
| tenaciousDaniel wrote:
| My comment is general enough to be easily interpreted as a
| question. If you have an as to how this proposal _is_ a
| necessary addition to WebGPU and WebGL, why not go with
| that, instead of snarky condescension?
| dangerface wrote:
| > WebGL exists, why do we need a budget restricted version of a
| model viewer in the browser?
|
| WebGL support on safari is ropey at best why would apple
| implement a standard written by some one else when they can
| create a new standard no one asked for?
| imwillofficial wrote:
| Proposing adding something to the HTML spec is not "creating
| a new standard no one asked for"
|
| Don't be deceptive. Inaccurate generalizations and hyperbole
| add nothing to the discussion.
| pessimizer wrote:
| Holding a knife and moving your hand back and forth is not
| killing someone, either, but my omission of a few important
| details is the deception. In this case, the something being
| added to the HTML spec is a new standard that they are
| creating. I'm not going to argue whether anyone asked for
| it, but "nobody" is obviously hyperbole; Apple is asking
| for it.
| imwillofficial wrote:
| Well there ya go, I called you on trite generalizations
| and hyperbole. Adding no truth or insight to the
| discussion.
|
| I for one think this is a future proofing move with
| little current utility. However I'm not one who thinks
| the AR/VR/ 3D Models in browser bandwagon is going
| anywhere within the next 5 years.
| zshift wrote:
| There are many developers, especially those just getting into
| the field, that don't understand how to work with WebGL. WebGL
| is a great fallback if you need/want more control, but having
| basic support for 3D elements is a great idea for someone that
| just wants to show it off.
| moron4hire wrote:
| Browsers do integrate with VR headsets.
|
| And it is awesome.
| gkilmain wrote:
| This is intriguing (and new to me). Can you point me to
| something you enjoy that I can look at? Not even sure what to
| search...
| astlouis44 wrote:
| Try vrland.io/lobby
| moron4hire wrote:
| The API is called WebXR (https://www.w3.org/TR/webxr/,
| https://developer.mozilla.org/en-
| US/docs/Web/API/WebXR_Devic...). You can find a lot of
| "getting started" samples here (https://immersive-
| web.github.io/webxr-samples/). Mozilla Hubs
| (https://hubs.mozilla.com) is publicly available. Message
| me and I will show you what I'm making at work (it's not
| exactly hidden, but it's also only meant for our existing
| customers and I don't need the extra traffic from posting
| publicly).
| vez- wrote:
| Check out "WebXR"
| marcellus23 wrote:
| Can you explain the steps necessary to display a 3D model using
| WebGL? (without using any 3rd party libraries). Could it
| possibly be easier than just pointing `src` to the URL of a
| model file?
| thrower123 wrote:
| What's the format of the 3D model? Are you going to build in
| support for all of the dozens of model formats that are in
| common use in every browser?
|
| Are you going to specify yet another new 3D model format as a
| standard target for browser to support?
| [deleted]
| marcellus23 wrote:
| Not sure where you got the idea of yet another format, no
| one seems to be mentioning that here or in the proposal.
|
| Presumably browsers would support the most popular formats,
| just as they do with images and video. And just as with
| images and video, we'll likely end up in a situation where
| m most formats are supported by most browsers, with a
| couple odd formats that are only supported by some. Doesn't
| seem like a huge deal.
| fenomas wrote:
| I'm only a casual at 3D, but my experience has always
| been that no two format implementations ever _quite_ work
| the same way.
|
| Unless apple is proposing to elevate some existing
| implementation, that already has interop across various
| platforms, then I think anything they do would
| necessarily be Yet Another Format.
| phkahler wrote:
| You can export 3D models to HTML using Solvespace:
| https://solvespace.com/index.pl
|
| These are fully self-contained in a single file along with 3js
| and can be added to web pages as shown here:
| http://m-labs.hk/software/solvespace/
|
| You can zoom and rotate the models on that page.
|
| That's been a feature since whitequark was the maintainer and
| worked for m-labs. And with the latest development branch you can
| link STL files too, so it can effectively be used convert STL to
| HTML.
| omneity wrote:
| Maybe the Safari team can consider implementing the existing
| specs that everyone else is supporting for years, before going
| overboard with stuff like this.
| avnigo wrote:
| Interesting use of the example image, I wonder if Apple is
| thinking of iMessage on the web, after we've seen FaceTime for
| the browser. I wouldn't have thought it a possibility, but it's
| strange they used that example.
| pier25 wrote:
| > _I wonder if Apple is thinking of iMessage on the web, after
| we 've seen FaceTime for the browser_
|
| My first thought was that Apple is indeed working on a VR
| and/or AR headset.
| chuckSu wrote:
| This is not a bad idea actually
| gfxgirl wrote:
| just fyi, while it's not exactly the same a <model-viewer> tag
| already exists
|
| https://news.ycombinator.com/item?id=28370584
| trey-jones wrote:
| Presumably if Apple is proposing it, then they are already
| implementing it in Safari and will eventually enable it, and
| either it will be terrible and nobody will use it, or it will be
| great, and the rest of the browser vendors will need to catch up.
| Brajeshwar wrote:
| We all don't like it but we are kinda inching towards a `Flash
| Player` in Browsers.
| tiborsaas wrote:
| We already have that for ages now with canvas and webgl.
| [deleted]
| dangerface wrote:
| I think apple should just fix their webgl implementation.
|
| They seem to be missing a fundamental feature of the web it's
| interactive. They have an interactive attribute for the tag but
| no description of what this means? What does it mean to interact
| with a 3d model? Can 3d model interaction be accurately defined
| in a single attribute? Why not just use javascript for that
| logic?
|
| The whole point of having multi media like a 3d model on a
| website is so people can interact with it. If the interaction is
| as simple as spin the model there are three.js and a million
| other javascript libraries that can do that in a few lines of
| code.
|
| Another fundamental the proposal doesn't address is the model
| format? As far as I know all model file formats are proprietary
| OBJ is probably the closest to an open standard and its anything
| but standard. Another issue that javascript easily solves.
|
| A fake problem their solution found is DRM, obviously the DRM
| could be removed as easy as HLS encryption (Super easy, did it
| yesterday). The main problem here is again the file format, no
| one would share their 3dmax file because its fucking huge they
| would export a low poly model for web that would be useless to
| anyone wanting to steal your model.
| TazeTSchnitzel wrote:
| > I think apple should just fix their webgl implementation.
|
| Safari is supporting WebGL 2 soon; it's already in preview.
|
| > Another fundamental the proposal doesn't address is the model
| format?
|
| It would probably be glTF.
| soylentgraham wrote:
| Its a few lines of code... for a coder, and even then, its 100
| lines of setup, shaders, model loading.
|
| Vs a single tag to embed a model. For a non-coder. You dont
| have to know how to encode/decode videos to add video to a
| page.
|
| Im surprised it's taken this long. (Whether it'll turn out
| good, not sure, but it will definitely be adopted, and fast)
| onion2k wrote:
| _Vs a single tag to embed a model._
|
| 3D models are complicated. If the <model> element is complex
| enough to support anything the user decides to embed then
| it'll put a huge burden on browser developers. That's fine
| for Apple and Google, but it'd be another nail in Firefox's
| coffin. On the other hand, if the element only supports (say)
| the gltf spec then it won't be a simple case of adding a
| model for a non-technical user. They'd need to export or
| convert their model, textures, shaders, animations, etc.
|
| 3D support is probably an order of magnitude harder than
| video. And video is hard enough.
| tehbeard wrote:
| > I think apple should just fix their webgl implementation.
|
| They can't even make a key-value storage that doesn't break
| every other release, you expect them to get something involving
| complex math to work?
| [deleted]
| jordigh wrote:
| If this gets accepted into webkit, which is now nearly synonymous
| with "HTML", would it be a huge porting effort to get this
| working with Firefox, the only other HTML implementation I can
| think of?
|
| (I understand that other webkit forks could have this code easily
| applied.)
| dmitriid wrote:
| > If this gets accepted into webkit, which is now nearly
| synonymous with "HTML"
|
| It's not synonymous with HTML. Chrome's browser engine is now
| unfortunately synonymous with "the web" in general. And, while
| it's derived from WebKit, it's diverged from it too far, and
| bears a different name,
| https://en.wikipedia.org/wiki/Blink_(browser_engine)
| thih9 wrote:
| > while we are not proposing a DOM for the data at the moment, we
| expect to in the future.
|
| On one hand this is exciting. On the other, I'm having trouble
| seeing practical applications. Can anyone point to some websites
| showing DOM use in existing media elements (e.g. SVG)?
| gambler wrote:
| DOM for SVG allows applying the same code that manipulates HTML
| to SVG with very little changes. You can splice it in with
| AJAX, change it via styles, etc. It facilitates writing generic
| scripts that can be reapplied to widely different use cases.
|
| The idea of having a generic interface to widely different
| types of entities is a very powerful concept and it is very
| unfortunate that so many web developers today don't seem to get
| it.
| thih9 wrote:
| I understand that it is a powerful concept; I'm looking for
| existing websites that make use of it; is anyone aware of
| any?
| theunspoken wrote:
| I am very fed up with standards lacking a free and open reference
| implementation. It's very easy to produce a specification for
| embedding 3D models into a browser, but who is going to follow up
| with and actual complying browser?
|
| The big guys, that's who.
|
| Google, Microsoft, Apple can just throw piles and piles of money
| at the problem; but what about everyone else? What about Firefox?
| What about Palemoon? What about Falkon?
|
| When the AV1 codec came about one of the first thing provided was
| the reference implementation (AOMenc), same with Wayland. Not the
| most performant, not the lightest on resources, but at least it
| followed the protocol.
|
| W3C and alike though don't seem to like this perspective. Why
| can't we have an average performing BSD-licensed W3C-compliant
| web browser? Just as a last resort if you just want to use
| something that is sure to work, or maybe the first browser you
| can port to a new architecture or OS to get things going.
| comex wrote:
| Google and Apple's engines are open source (and Microsoft now
| contributes to Google's). What would be the benefit of a
| separate reference implementation of this standard? I suppose
| it would be easier to port to other browsers if it were
| designed as a standalone library rather than tightly integrated
| into an engine. But the idea of going to pains to design a
| standalone library seems to contradict your later statement
| that you want an entire reference browser.
|
| A web browser is orders of magnitude more complex than a video
| encoder or a Wayland server. Not aiming for high performance
| would make a browser a little less complex, but not by much, so
| there doesn't seem to be much point. Minus that, you're just
| asking for someone (who?) to write a new web browser from
| scratch. It would certainly be nice if there were more
| independent web browser codebases in general, but I don't see
| what special benefit a new one would bring to the table just
| due to being marked as a "reference implementation".
| enjikaka wrote:
| No need for such an element. It's such a private use case to
| display 3D models that it's better suited as a web component than
| an element in the standard. See for example <model-viewer>
| https://modelviewer.dev/
| zemptime wrote:
| This should be much further up than where I found it!
| c7DJTLrn wrote:
| Yes, we need more features in browsers. There just aren't enough.
| It's just too restrictive. We don't need to carefully consider
| the tradeoffs.
| cblconfederate wrote:
| models are heavy though. imagine sketchfab with models instead of
| images, is that so useful?
|
| Isn't model loading/viewing supported by webXR? currently it
| seems webXR requires a lot of boilerplate to get it to work, it
| would be nice to have a simpler way to setup a 3d scene , and
| html tags should follow.
|
| Also , limiting the functionality to 3d models seems odd, how
| about 360 panoramas, and what about animation?
| Waterluvian wrote:
| Interesting. So Apple wants better browser AR support for their
| upcoming goggles?
| BiteCode_dev wrote:
| Yes, but something you can't manipulate client side because we
| don't want those hippies to have control of the next web thing
| this time.
| snet0 wrote:
| Assuming I'm reading your snark correctly, is this really such
| a bad thing? People here seem to have a rose-tinted view of the
| internet's past, before Google, Apple et al. "abused" their
| browsers' position to push changes into the spec.
|
| I can certainly see that apparently there are a lot of HN
| commenters who would like to go back to the days of IE and no
| real web technologies or much progress, but I think practically
| everyone outside this bubble prefers their browser experience
| to be at least somewhat feature-rich, and while the proposal
| under question may be strictly unnecessary, it should be
| weighed against alternatives: bundling a model viewer with
| every page view.
|
| Maybe this proposal is bad and a waste of resources, but I
| don't like the knee-jerk response of digging one's heels in and
| decrying any and all browser APIs as bloat.
|
| Not entirely directed at you, but your response just seems to
| echo something I see very often.
| moron4hire wrote:
| Agreed. There is another poster in this thread commenting
| about "privacy". There is a certain class of perfect privacy
| fetishist that is completely blind to the fact that that
| particular horse has long, long bolted out the stable.
|
| All these arguments serve, when they are successful in
| hobbling the browser as an app platform, is too push
| developers into native apps in the app store. And then the
| developer doesn't need to fingerprint you, they get your
| identity just for asking.
|
| Meanwhile, browsing habits (sites visited + time of day of
| visit) is enough to fingerprint the vast majority of people.
| And sites _do_ collude on the backend to share this data with
| advertisers, long before the user ever gets a chance to block
| it in the client app.
|
| If privacy fetishists see the browser as a sinking ship, they
| don't seem to realize they are trying to bail out the Titanic
| with a teaspoon, or that there is no such thing as dry land.
| The only way to stay private is too stay off the network
| entirely.
| matsemann wrote:
| I don't mind new capabilities, but I hate how many new
| browser features are "standards" invented by Google for their
| own products which everyone else have to implement to remain
| a competitive browser.
|
| Not fan of the prospect of Apple doing the same. If I wanted
| to make what Apple is making, I would have to rely on webgl.
| Them inventing something for their own use case when other
| stuff exists feels just unnecessary. Their proposal also
| includes a 3d format no one uses (except them I guess), as an
| attempt to shoehorn it in or something.
| snet0 wrote:
| While I do accept the point, I think part of this is just
| that Google and Apple are the companies doing a large
| amount of work in the browser space. Because of this, they
| are likely to be the companies who see the hole that should
| be filled, or the opportunity to improve something.
|
| Who are the people that should be making browser spec
| proposals, if not the people building browsers?
|
| Yes, it sucks if you want to write your own browser, and
| now have to play catch up with the big boys throwing their
| weight around. But I don't think this is points against
| Google or Apple. Our browser technology shouldn't be held
| back by some romantic dream of individuals being able to
| build one from scratch, despite what many HNers seem to
| think. Even the best mechanics and engineers will struggle
| to build a car comparable to whatever rolls off of the
| large production lines. (I understand maybe that's a poor
| analogy, since you don't _need_ all the bells and whistles
| of a new Toyota to be road-legal, while you do kind of need
| to keep up with the spec in order to be internet-usable
| (although there still are some IE11 holdouts..)).
| matsemann wrote:
| My point isn't from a "a single person should be able to
| build this" perspective. But from a "big players misuse
| this to grab market share" perspective. Like how youtube
| was slow in Firefox for years, since they used APIs only
| existing in Chrome. Others follow suit, and thus other
| browsers are forced to either implement the same thing
| (thus making it a "standard") or lose market share since
| stuff works better in other browsers.
| snet0 wrote:
| Sure, this sucks. I guess the counterargument is that
| then, given that the new API in Chrome _is_ an
| improvement over the standard, waiting for this API to be
| actually accepted and written into the spec is a long,
| arduous process during which Chrome is unable to
| implement an objective improvement to their user
| experience.
|
| My concern is basically that if we force browsers to be
| spec-compliant and wait for the due process concerning
| new features, we pump the brakes on everything, and we
| risk stalling genuinely beneficial updates.
| jkelleyrtp wrote:
| I don't think the original comment had snark. I interpreted
| it is speculation around the rumored AR goggles.
| Waterluvian wrote:
| Zero snark in my comment.
| snet0 wrote:
| Okay, if I misread that I apologise. I'm not following the
| rumors, so it seemed like "oh looks like Apple's coming out
| with another something something and needs to update the
| spec to handle it". I think my point remains, though.
| evrflx wrote:
| I would love to see that apple negotiates their wishes but have
| in turn to implement web APIs they currently keep back by choice.
| And let users use a real different browser on their device.
| achairapart wrote:
| Google: "Hey Apple, here is your pet <model> tag for your next
| AR/VR secret project. Now, here there are all the PWA APIs that
| are still missing in Safari. Thank you."
| purplejacket wrote:
| I want a <latex> element.
| JusticeJuice wrote:
| 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/
|
| 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.
| gfxgirl wrote:
| 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 wrote:
| > 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.
|
| Yay! OpenGL with extensions all over again
| pjmlp wrote:
| It never stopped being an extension spaghetti, Khronos
| loves extensions.
|
| https://webglreport.com/?v=2 reports 10 extensions.
|
| And you can get the full spectrum over GL, GL ES and
| Vulkan, here https://gpuinfo.org.
| Joeri wrote:
| 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 wrote:
| yes and an example already exists here
|
| https://modelviewer.dev/
| baybal2 wrote:
| You can already embed VRML
| CrazyPyroLinux wrote:
| I was just coming here to say this, but as a joke. :)
| Jasper_ wrote:
| 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?
| [deleted]
| ruined wrote:
| >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 wrote:
| Seems already possible using a custom web component.
| southerntofu wrote:
| Sure, but that doesn't make standardization useless so
| people stop reinventing this same wheel over and over
| again for very basic needs.
| Jasper_ wrote:
| I wouldn't call "display a chair in a web page in an
| inexact and implementation-defined manner, with air
| quotes 'interactivity'" a "very basic need".
|
| This seems like a very specific use case, which I think
| is best left to custom code.
| oneplane wrote:
| 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 wrote:
| Mistake was made when adding Javascript.
| southerntofu wrote:
| 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.
| sam0x17 wrote:
| 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.
| fluxem wrote:
| 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).
| dsign wrote:
| 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 wrote:
| 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.m...
| mikepurvis wrote:
| 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.
| brundolf wrote:
| 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
| truted2 wrote:
| 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.
| mistersquid wrote:
| > 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#cons
| ide...
| phkahler wrote:
| >> 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
|
| Examples: http://m-labs.hk/software/solvespace/
| stefan_ wrote:
| 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.
| spiderice wrote:
| > Nobody uses the native input elements
|
| This is definitely not true. Not even close.
| crazygringo wrote:
| > _Nobody uses the native input elements_
|
| What are you talking about? The vast majority of sites use
| native input elements.
|
| The percentages are going to be different, though, depending
| on whether you're talking about text boxes, dropdowns, or
| date pickers. (After all, Safari only introduced native
| support for date pickers this past April, according to MDN's
| compatibility table [1].)
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/HTML/Element/in...
| somishere wrote:
| Safari supports date pickers now?! Wonders will never
| cease.
| jeroenhd wrote:
| 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 wrote:
| 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.
| brundolf wrote:
| 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 wrote:
| 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.
| yayr wrote:
| We will need a full 3d rendering space for future applications
| anyway. It will require, that 2D content can be embedded in a 3D
| space and vice versa. Also a standardized 3D dom (with whatever
| usefully condensation of properties) will be required sooner or
| later, unless we want only some very big players to provide
| proprietary 3D environments.
|
| I think, a "model" tag is a good and forward compatible path
| MR4D wrote:
| We have a video tag, so why not?
|
| https://www.w3schools.com/html/html5_video.asp
| otrahuevada wrote:
| The naming is unfortunate.
|
| But also, it'd be pretty cool if this was implemented as a
| browser extension, that way it could be much faster to iterate
| over.
|
| I wonder why this is not common practice? Modifying browser
| internals is such a pain that it strikes me as odd that it is the
| 1 established way of going about this proposals.
| zodiakzz wrote:
| If I am not wrong, a functional version can be written in plain
| JS (+ WASM?) using Custom Elements (tho tag names must contain
| a hyphen). Except I don't know why all the non-Google
| stakeholders are hell bent on sabotaging Custom Elements. While
| Google is doing so much innovation in that space. Strange.
| kreetx wrote:
| Came here to say that. They could do a custom element
| implementation, perhaps ship that (in their own namespace),
| offer polyfills for other browsers and go on from there.
| pjmlp wrote:
| Not only it can, it already exists.
|
| https://modelviewer.dev/
| davidgl wrote:
| What about the old vrml standard ? I remember playing with 3d in
| the browsers in the 90's https://en.m.wikipedia.org/wiki/VRML
| Minor49er wrote:
| I remember a browser plugin + a bunch of demos and tutorials
| being included on a Tomb Raider game long ago (Tomb Raider III
| Gold, most likely). I remember VRML being pretty easy to
| understand.
| throw_m239339 wrote:
| Of course that spec will also have to specify the format are
| supported just like WebSQL had to specify the SQL flavor used ...
| Oh wait, that was the excuse not to make WebSQL a standard... img
| or audio or video never specs never needed to specify which
| format these tags should support, but it was a problem with
| WebSQL? I'd rather have WebSQL than a <model> tag...
|
| Also, let's continue with the hypocrisy. If indexedDB is good
| enough so people "just have to implement a RDBMS on top of it",
| so is WebGL which had poor support on Safari until very
| recently...
| varjag wrote:
| Just embed a .vrml in a <frame>.
| EamonnMR wrote:
| A model is no better than a image without animation. So at the
| minimum it needs to support animation. But of course an animation
| with no interactivity is no better than a video. So it needs to
| support interactivity. Now you're talking about a bunch of
| scripting, to which (as they point out) Babylon and Three.js are
| well suited. I don't see the point of adding this to the browser
| when canvas exists, unless the point is to take components out of
| Babylon/Three and put them into fast browser code.
| twirlock wrote:
| This is a terrible idea, and that's not what model means, not
| even in computer science jargon. Apple needs to fucking calm
| down.
| max_ wrote:
| How is this different from WebGL?
| azangru wrote:
| Same way html canvas + javascript is different from the img
| tag, I suppose
| tiborsaas wrote:
| No JavaScript
| arduinomancer wrote:
| I'm guessing they're aiming for something similar feature-wise to
| the 3D model viewer built in to Windows 10.
|
| A lot of people don't know it exists. It actually supports glTF
| 2.0 models with PBR textures, which I thought was pretty advanced
| for a preview application.
|
| If you're curious go download this sample glTF model and open it
| on windows: https://github.com/KhronosGroup/glTF-Sample-
| Models/tree/mast...
|
| Still, it could be a can of worms because there's a ton of stuff
| that would need to be specified like camera, lighting, etc.
| atum47 wrote:
| When I was building my 3D engine for the web I thought about
| creating a component for this kind of thing: showing and
| interacting with a 3D model (I think this would be good for
| stores to display products) and I also thought about displaying
| panoramic images (inverted sphere with a 360o picture as
| texture), back then I found some other people doing something
| similar so I just gave up on the idea. But I for one think this
| would be a good feature.
| ape4 wrote:
| Any possible privacy implications? Perhaps the model could be
| used for tracking?
| mishafb wrote:
| I don't think you can use JS to get how the model looks on
| screen with this, whereas a canvas can be converted to an RGB
| grid
| simonke wrote:
| A new element like canvas, except that model should be allowed to
| only draw 3d scenes? At this point they should just implement the
| w3c X3D specificiation into the browser with an integrated
| renderer (like SVG), so that we do not have to rely on x3dom
| anymore. Since SVG is not blocked, I do not see why X3D would be
| blocked.
|
| https://en.wikipedia.org/wiki/X3D
|
| https://www.x3dom.org/
| sorenjan wrote:
| I think such an element would be welcome, and make it easier to
| add 3D elements to websites. A while ago I wanted to share some
| 3D models with people, but there weren't any good options. I
| found a couple sites that lets you upload .obj files, but you
| need an account and they worked by embedding renderers in
| iframes. If 3D models had better browser support I hope there
| would emerge some sites that would let you upload and share them
| as easy as regular images now.
|
| I don't think it's stranger than having a video tag even though
| we could embed video without it previously. Having a dedicated 3D
| tag would make websites more semantic. Hiding stuff in canvas
| tags like Googles Flutter is the wrong way to go, so bringing
| stuff out of canvas tags when possible should be encouraged.
|
| Edit: I also think this can be compared to the svg tag. Sure, you
| could use canvas and webgl and render a 2D vector image using
| some javascript library. But with svg, you don't have to, and you
| can style it with css etc.
|
| I don't agree with the tag name though. IMO, "model" is a
| singular 3D object. Such a tag should support scenes with
| multiple objects in them.
| josefx wrote:
| > I don't think it's stranger than having a video tag even
| though we could embed video without it previously. Having a
| dedicated 3D tag would make websites more semantic.
|
| Video had literally thousands of commonly used sites embed
| third party players before we got a standard.
|
| > A while ago I wanted to share some 3D models with people, but
| there weren't any good options.
|
| So in contrast to video no one gives a shit?
|
| > If 3D models had better browser support I hope there would
| emerge some sites that would let you upload and share them as
| easy as regular images now.
|
| We have APIs to render 3D content (WebGL) have APIs to load
| random files from a site what more do you need for obj files?
|
| > I don't agree with the tag name though. IMO, "model" is a
| singular 3D object. Such a tag should support scenes with
| multiple objects in them.
|
| And what format will you use to describe these Scenes? obj
| doesn't handle animations or complex structures. What you want
| isn't a browser but a complete game engine.
| sorenjan wrote:
| > Video had literally thousands of commonly used sites embed
| third party players before we got a standard.
|
| Yes, and now I can right click a video and open it in it's
| own tab, pop it open in an overlay, or download it easily.
|
| > So in contrast to video no one gives a shit?
|
| It's historically been more difficult to create 3D models
| than images or video. Now phones have lidar, photogrammetry
| is becoming more accessible, there are ML models that create
| 3D from 2D, 3D printers have been around for a while, etc. 3D
| could be more popular if it was easier to share and display.
|
| > We have APIs to render 3D content (WebGL)
|
| That gives you a GL context, then you need javascript to
| render the scene and add interactivity from mouse events etc.
|
| > have APIs to load random files from a site what more do you
| need for obj files?
|
| Something like imgur where I can upload a file and send the
| link to people, and have it work in their chat client and
| browsers. Something that makes it easy to add a 3D
| visualization to articles.
|
| > And what format will you use to describe these Scenes? obj
| doesn't handle animations or complex structures.
|
| Apple uses the USDZ format in their examples, and there's
| also the glTF format. But obj and stl files should be
| supported as well.
|
| > What you want isn't a browser but a complete game engine.
|
| Game engines does much more than render 3D scenes. They also
| handle image loading, audio, video, network connections, user
| input... You're right, browsers does have a lot in common
| with game engines.
| josefx wrote:
| > 3D could be more popular if it was easier to share and
| display.
|
| Could be more popular? The APIs are already there,
| literally nothing stops you from writing a pure js lib that
| supports 3d models in a way that you want and can be reused
| on any site that needs it.
|
| Video didn't have that, video needed 3rd party plugins to
| even run. Video still managed to attract a sizeable user
| based before that.
|
| > You're right, browsers does have a lot in common with
| game engines.
|
| The same way a toaster and a fridge both handle food. Of
| course I am all in favor of dropping Chrome for Unreal I
| think the later doesn't call home half as much.
| sorenjan wrote:
| > Could be more popular? The APIs are already there,
| literally nothing stops you from writing a pure js lib
| that supports 3d models in a way that you want and can be
| reused on any site that needs it.
|
| The APIs are there, but not the renderer or a way to
| interact with it. I'm looking at it as a consumer, not a
| web developer. I don't want to have to write a library or
| use someones else's, that's the point. Browsers have
| native video controls when embedding mp4 files with the
| video tag, you could argue that could be done just fine
| with html and javascript instead.
|
| > video needed 3rd party plugins to even run. Video still
| managed to attract a sizeable user based before that.
|
| Of course video attracts lots of users, that one of the
| main use of internet for many. Besides Netflix and
| similar streaming, looking at short clips on Facebook and
| Reddit is why a lot of users open their browser in the
| first place. Should everything that's not as popular then
| be dismissed? Should we not have svg support in browsers?
| Should video decoders be shipped as webassembly blobs?
| Should we do like Google docs and render the whole page
| in a canvas tag?
|
| > Of course I am all in favor of dropping Chrome for
| Unreal I think the later doesn't call home half as much.
|
| Unreal uses Chromium Embedded Framework, so all you need
| to browse the web is the Unreal Engine and a build
| environment, and you can make your own web client. No
| need for extra browsers.
| josefx wrote:
| > I'm looking at it as a consumer, not a web developer
|
| Then why do you care if it is part of the browser or just
| a library? A consumer doesn't need to know that,
| certainly wont interact with a model element directly.
|
| > you could argue that could be done just fine with html
| and javascript instead.
|
| Not at the time the video controls where introduced and
| now many sites use DRM which would prohibit a pure js
| implementation unless you want to piss of Netflix,
| Amazon, etc. .
|
| > Should everything that's not as popular then be
| dismissed?
|
| There are finite browser developers working with finite
| time and finite resources. Why spend any of that on
| something a random web dev. can easily implement as a JS
| library?
| peanut_worm wrote:
| While I agree that Apple should fix their WebGL implementation,
| this doesn't seem like such a bad idea.
|
| I have noticed a lot shopping sites now have 3D models of
| products that you are buying, I feel like this element would be a
| great match for those situations.
___________________________________________________________________
(page generated 2021-08-31 23:02 UTC)