5 ms·
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 Pa
by 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 agoSeems already possible using a custom web component.
- oneplane 5y agoYou 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 agoMistake was made when adding Javascript.
- southerntofu 5y agoSo 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.
- still_grokking 5y agoThere is no "semantic aspect" of the web. The semantic web is dead since invention. It makes no difference that you now call some boxes with some new names as those boxes get custom styling and behavior anyway. There is no semantics (no meaning) behind the names. Even there are proposals how to use elements "semantically correct" nothing enforces it. So it's useless in the big picture. You can't rely on any semantic meaning. As a trivial example, everybody is free to put a h1 below a h6. It will "work"… Because there is just no semantic meaning to those names! Things like Gemini are interesting as they show a route to tech that separates again documents and applications working with documents. Gemini tries to get the document part right I think. Only in a model where you don't strive for pixel perfection and customizable behaviors for every piece of rendered content something like semantic meaning of those peaces could arise: There would need to be some agreed meaning because the client would be in charge of rendering and bringing everything to live. But this model is not the web. Not any more…
- southerntofu 5y ago> As a trivial example, everybody is free to put a h1 below a h6. It will "work"… Because there is just no semantic meaning to those names! Well you took the most obvious counter-example, but there's plenty of semantics in HTML. See for example picture/source element, or audio/video. Both as a user and website operator who deals with people in several languages, i cannot have strong enough words for my appreciation of adding subtitles to a video using just `<track kind="subtitles" srclang="en" label="English" src="foobar.vtt">` without having to modify the media container server-side as previously. Little features like this may sound insignificant to you if you only use the web for forums and blogposts, but they're in my view a great accessibility/internationalization win. h1-h6, unless used in a serious publication, has indeed no semantic meaning other than "make that one bigger than this one". But for deeper semantics, there's schema.org microdata and indieweb.org microformats, which enable deep interoperability/federation between websites with entirely different tech stacks. I would personally appreciate if either/both were standardized as part of the Web instead of the entire JavaScript craze, but saying the web has no semantics is ignoring decades of innovation in this field with very practical applications and i don't think that's very fair. > separates again documents and applications(...). Gemini tries to get the document part right I think. I strongly appreciate this separation, as i'm personally interested in document browsers, not applications platforms (i've already got an OS and desktop environment for that). However, i'm not sure gemini gets it "right" (very subjective). I like that there is a document format focused on plaintext UX, and i very much intend to support it on my websites sooner or later. I'm part of the tildeverse where gemini grew and is nowadays thriving. However, in order to reduce bloat, gemini has pretty much given up on every useful semantic aspect of the web. What's left in gemtext is: one-level lists, three-level headings, and preformatted text (code/quotes). No more alternative text for linked images (unless you want it displayed for everyone including clients like lagrange which support inline images), no more federated mentions/replies like indieweb.org, no more scraping... > Only in a model where you don't strive for pixel perfection and customizable behaviors for every piece of rendered content something like semantic meaning of those peaces could arise (...) this model is not the web. Not any more… I'm not sure that's entirely true. Some part of me agrees with the argument, but on the other hand i don't see a reason why a proper semantic markup couldn't provide a suggested pixel-perfect layout which the browser could freely ignore to make its own. Also, when you disable JavaScript entirely, the web is a very capable semantic document platform. All in all, i don't have a clear opinion on the topic. But i'm sure it's worth investigating. I'm all ears for resources and projects in such directions (either more semantics in gemini, or less interactive stuff in the web). Thanks for taking the time to come up with a thoughtful answer!
- southerntofu 5y agoSure, but that doesn't make standardization useless so people stop reinventing this same wheel over and over again for very basic needs.
- Jasper_ 5y agoI 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.
- southerntofu 5y agoSorry "basic needs" refered to "basic needs" in terms of 3D rendering. It was an answer to people elsewhere in the thread complaining that this new element would not support lighting and other sophisticated 3D rendering features. I agree that 3D/VR is definitely not a basic need for the web and i personally don't want/intend to use it. That being said, if there is an established 3D model standard, i think it's better overall if the browser implements it properly, rather than having two dozen half-baked JS implementations eating all your CPU/RAM just to display a tiny square. Just like technically you can parse an MP4 video frame by frame using JS to display each frame in a canvas, doesn't mean you should. <video> element is much better suited to that, and if that element had not been standardized, we would arguably have to choose between "Youtube browser" and Flash player fallback, which is arguably worse for everyone involved. PS: Also as other have pointed out in the thread 3D on the web is over two decades old yet has never been standardized. See also https://en.wikipedia.org/wiki/VRML https://en.wikipedia.org/wiki/VRML
- 8note 5y agoIsn't that to say it adds a model that you can't see? It's just an invisible element on the page? If it's not being rendered, what are you seeing? If it is being rendered, what are the shaders? Camera? Etc that webgl solve? Or are these not essential complexity?
- deleted 5y ago[deleted]