immersive-web / model-element

Repository for the <model> tag. Feature leads: Marcos Cáceres and Laszlo Gombos
https://immersive-web.github.io/model-element/
Other
62 stars 11 forks source link

Need for Planning and Justification #70

Open DR-xR opened 10 months ago

DR-xR commented 10 months ago

/tpac

I have read through the issues opened/modified in the last year (at least as my eyes could identify them). A number of issues address details of what the <model> element should or should not do. There is one (#55) that seems to address overall issues and several (#54, #57, #63, #67) that are asking for more fundamental design steps to be carried out.

I agree that there needs to be more fundamental design, but I would like to see use cases (#67) and a analysis of what some existing (mentions in #55 and #63) do or don't do that needs to be included in a new element. I am not claiming that the existing display systems are perfect, but it would be good to know what this proposed element would/could do that is not currently supported.

We can argue about the fine points at each TPAC; but without an agreement on what a new element is trying to achieve, we are discussing vaporware.

To help kick-start this effort and not claiming to be an expert in any of these systems/options; I present a starting list of items for comparison. By no means is this list complete, and I am not going to evaluate the various systems.

  1. Supports glTF Core (V2.0)
  2. Supports glTF PBR extensions
  3. Supports glTF geometry compression extensions
  4. Supports glTF image compression (KTX) extensions
  5. Anticipated time from extension release to support
  6. Consistent rendering across browsers
  7. Control (using attributes or equivalent) of model features (animation, lighting, etc)
  8. Methods for setting scene lighting
  9. ... (add more items below)

The systems that should be compared include (add others below)

  1. <model-viewer>
  2. <model>
  3. <x3d> (as implemented in x3dom, x-ite or others -- all support loading glTF files)

A filled-out comparison table along with use cases describing features not yet available would go a long way to helping everyone figure out what is important and where to spend time & effort.

KooIaIa commented 10 months ago

Hello, I can't attend the meeting tomorrow but wanted to throw in additional perspective and a thought experiment that is at a high level vapor-y but in a good way.

image

Question: How would you create the WebXR logo in WebXR with web standards?

Possible Answers: 1 \<model>, 2 \<model>, 2 \<img>, 2 \<canvas>, 2 \<html>

I'm excited to one day create the WebXR 3D Logo out of two \<img> tags in VR. We can't use \<img> tags in WebXR intuitively today - but using \<img> and \<model> intuitively in the Web in XR with all the web's amazing powers is my main goal.

Yonet commented 9 months ago

Discussion minutes from TPAC: https://www.w3.org/2023/09/11-immersive-web-minutes.html#t03

AdaRoseCannon commented 9 months ago

https://www.w3.org/2023/09/12-immersive-web-minutes.html#t03

DR-xR commented 8 months ago

This repo has been around for almost 2 years and very little progress has been made, even to the point of not having a plan to be able to complete or close the work here. It wasn't until this last TPAC that a justification for creating a new element was provided. There still are a lot of open issues on rendering and basic handling. There is a new one on making the entire structure modern-web compatible (#73).

I am not looking to resolve all issues soon, but to develop a plan whereby all of the issues can be addressed. The initial comment for this issue is not the only way to proceed. The WG/CG should develop a means for getting to the end of this so any browser builder can address the need described in this repo in a consistent and standard manner.

/agenda

cabanier commented 8 months ago

@DR-xR I think we made a lot of progress at TPAC towards convergence. A big stumbling block was that USD was a non-standardized format but it looks like that is being addressed. I personally would be ok with just supporting that and not GLTF as it will make our developers' and our life easier. I suspect that there will be more clarity in the coming year as vendors experiment with this new tag.

cwilso commented 7 months ago

@cabanier Can you explain "but it looks like that [USD being a non-standardized format] is being addressed"? I'm not clear what's changed. Although there is work on USD, it's still not clear where to look for a single, cross-platform-implemented specification.

cabanier commented 7 months ago

@cabanier Can you explain "but it looks like that [USD being a non-standardized format] is being addressed"? I'm not clear what's changed. Although there is work on USD, it's still not clear where to look for a single, cross-platform-implemented specification.

See https://aousd.org/ I don't know how far along the spec and reference implementation is but it looks promising.

zachernuk commented 7 months ago

See https://aousd.org/

We're hoping to have a solid spec next year that addresses the core needs for the format - I'm not participating directly but will report back what I hear.

DR-xR commented 7 months ago

The USDZ format that is used on iOS devices is not a zipped version (either archive or compressed) of all of USD. To start with it is only UsdPreviewSurface. It does not implement many of the PBR features found in MaterialX, OpenPBR, or Khronos PBR (the one used for glTF). Many companies displaying products do not like the lack of material features in USDZ for iOS.

Now if the use cases do not require advanced materials or comparable features, then USDZ may be exactly the correct format. It is worth noting that Khronos has released an app as open source for viewing glTF files on iOS devices. It is described in the blog post (with links to the app, and open source GitHub).