Giter Site home page Giter Site logo

Comments (3)

Mugen87 avatar Mugen87 commented on June 28, 2024 2

I've mentioned this topic in #28639 (comment).

It would be a help if USDZLoader could internally use a USDA parser that returns a JSON representation of the asset with object types representing the different USD classes. In this way, it would be easier and cleaner to traverse through the hierarchy and identify/process nodes. Right now, we have to do a lot of string testing to identify nodes (like name.startsWith( 'def Material' + id ) which is far from ideal.

However, after working at the latest issues, I have realized this is not the actual major issue. It's the fact that USD is an incredible complex format that will be hard to implement and support. Reminds me a bit at Collada and FBX^^. It seems the goal is to provide a format so teams with different authoring software can work on common scenes. Such a focus means respective 3D assets tend to be expensive to deliver and parse on the client side, though.

I'm not sure what to kind of goal we should have with USD in three.js, tbh.

from three.js.

Mugen87 avatar Mugen87 commented on June 28, 2024 1

I can reproduce with all files. They render a bit differently with the current dev version of USDZLoader since a few fixes were applied lately. However, the loader is still unable to load the files correctly.

USDZLoader only supports a very specific structure of USDA files right now. Other spec-conform structures like the ones from your assets are not supported. To me more precise, your USDZ assets define the materials outside of a XForm instance. Besides, they use additional Scope definitions insides Material definitions which is also something the loader does not expect.

The loader needs a different implementation regarding how to resolve paths and ids like the values assigned to connect and binding properties. Otherwise it will be unable to find the correct definitions like in your assets.

from three.js.

zaesur avatar zaesur commented on June 28, 2024 1

I would like to contribute to this issue, but it's beyond my capabilities. However, it touches on a fundamental question about USD and three.js, which I have been asking myself.

A few years ago, Autodesk demo'ed USD in the browser. There is also a USD web visualization project ran by the Academy Software Foundation. What is the current status of these projects? Can these efforts help three.js avoid having to create a custom parser which has to be kept in sync with a living standard?

from three.js.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.