Skip to content
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

Textures not rendering for Sketchfab export #311

Open
gjcope opened this issue Oct 11, 2024 · 2 comments
Open

Textures not rendering for Sketchfab export #311

gjcope opened this issue Oct 11, 2024 · 2 comments

Comments

@gjcope
Copy link
Collaborator

gjcope commented Oct 11, 2024

Per @Cook4986 (IQSS/dataverse.harvard.edu#306) Sketchfab exports are not rendering textures correctly.

This looks to be a lack of support for the unlit Three.js MeshBasicMaterial.

@gjcope
Copy link
Collaborator Author

gjcope commented Oct 11, 2024

A quick and dirty proof-of-concept for unlit material support is here: https://github.com/Smithsonian/dpo-voyager/tree/dev-basic-material though there are definitely some aspects of our material options (and obviously lighting controls) that don't really work in this scenario. Maybe we consider converting unlit to lit? @Cook4986 is there a specific reason you need unlit models or is this an unintended artifact of the Sketchfab export?

@sdumetz If we do end up mapping basic to physical materials, it might be worthwhile bringing back a custom copy method (#188) to make things cleaner...

@sdumetz
Copy link
Contributor

sdumetz commented Oct 15, 2024

I don't know, the copy method should work for any material no?

we should probably look for a way to extend materials without having to duplicate so much code because they are a bit painful to update on each THREE.js upgrades and this code is error prone (which was the reason behind #188).

Maybe Clay/XRay/Wireframe could be moved to a separate standalone material?

Cut Plane and Overlays can't be separated from the material's code but maybe something like ExtendMaterial would work?

Do you think we could isolate necessary changes to the GL fragments to the beginning/end of the file and just concatenate it with whatever THREE is shipping? That would make supporting many materials much less code-intensive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants