-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Size/performance comparison to COLLADA #28
Comments
I'm writing a collada.js loader - did not like the ones I've seen so far.. On Wed, Mar 20, 2013 at 5:52 PM, Patrick Cozzi notifications@gh.neting.ccwrote:
|
as a side note, feeding three.js with glTF works as the example shows, but not the best case scenario. |
There are MANY issues with Three.js. The COLLADA loader is not good. I have fixed several serious bugs in there, including ahem lights were never even implemented. So anything people do in this area would be great. FYI at some point, soon, I will put in a pull request with Ricardo to get these changes pushed back into the mainline. |
If we can find someone to code it, it would also be interesting to show loading performance of glTF vs. a completely binary format. Depending on packaging, glTF is most likely a tad slower, but probably not significant enough to turn folks off. |
IMO depends mostly if you have very big node hierarchy... |
We can use some of the numbers in #395 |
Now part of #456. |
JSON schema cleanup for EXT_mesh_features
This is a new github label for developer outreach ideas, e.g., demos, publications, presentations, etc. Anyway...
When glTF stabilizes, it would be good to show some size and speed comparisons to COLLADA or even other formats to help motivate glTF. Even compare amount of code needed to write a renderer. Perhaps we can use Three.js, which already supports other formats for the load speed comparisons.
The text was updated successfully, but these errors were encountered: