Is this also related T277930?

Here is a proposal on Commons with quite a lot of interest in the topic: https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Enable_textured_3D_files_on_Commons

In T246901#9054129, @Kristbaum wrote:

Here is a proposal on Commons with quite a lot of interest in the topic: https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals#Enable_textured_3D_files_on_Commons

The discussion was closed successfully with: "Broad consensus for allowing this."

What should be the next step?

Would be great if some epic task could be created that tracks all more of the actual implementation tasks for different file formats, most of which haven't moved forward for some time e.g T184803 or T100081. And of course adding it to some higher priority queue would be very appreciated.

I suppose T44725 is too all-encompassing for what you have in mind?

We do need some tractable way to divide and conquer this issue: it's obvious to some people that we should support a much wider range of formats (as that would bring in more users, use cases, devs caring about those formats) but the Uncertainty and Doubt around what's involved in integrating a new format is diffusing that energy -- even when, as in this case, it's a large source of new knowledge, connected to many other collaborative communities, and supported on Commons.

1. @Aklapper you proposed closing T44725 some time back as being too large / vague / undirected compared to other options; how do you see this family of requests and threads being better organized?
2. If the WMF doesn't have anyone responsible for currently prioritizing adding new formats, can we turn these ~20 steps into more of a checklist that anyone can make progress on for a given format or family of formats, reducing the core-dev decisions to a security review + performance review + integration after all the rest has been sorted?
   1. In that case can the checklist for a particular format reside on a wiki? Phab doesn't quite seem ideal.

@Sj: I likely do not have a good answer. All I can say is that I believe that a ticket which covers anything related to any file formats related to what individuals may interpret into the term (multi)media is an extremely wide scope these days. :) Your mileage may vary, of course...

Did we already examine what file type(s) are most suitable for textured meshes?

Then we can figure out what we have to take care of when implementing and what viewer is recommended.

For the point cloud files, I made a suggestion for LAS as filetype (T100081).

Note that improving media file format support is still not something that's explicitly receiving resourcing at Wikimedia Foundation, so it's good to have a low cost in terms of implementation work (note that this includes thumbnailing via thumbor, an entirely separate package), low risk in terms of tooling safety from libraries and executables used in rendering on the server or client side, an easy way to embed the resulting view into mobile apps without too much platform-specific coding, and an easy safe way to downgrade support if security problems are found in the future.

Remember this needs to be done with no dedicated team for file format or image/media embedding or maintenance of that code and infrastructure.

[Note: in general pulling in binary file parsers/renderers is a big extra security risk for server-side execution. Pulling in a large JavaScript rendering library is also a security risk for client-side safety, as it could expose an XSS injection vector in the library that can be used against the entire page. So there's a relatively high bar, and we've seen problems in production for real with Graphs etc.]

So if we add server-side rendering, we need a clean way to sandbox it, that works both in standalone installs and via Thumbor, and can be relatively sensibly managed and packaged, and made disableable with a switch-flip. I'm also hoping to work on some iframe sandboxing stuff for media embedding, which will later be usable in stuff like media renderers (which we can port the existing video & 3d interfaces into when it's ready)... I think we've got some tasks open for that related to Graphs, I'll track that down later :D

A few thoughts:

1. In all major JavaScript WebGL libraries (three.js, Babylon.js, PlayCanvas, ...) the preferred model format for display is glTF 2.0. It is lightweight compared to alternatives; supports meshes, lines, and point clouds; provides more modern/advanced material appearance definitions; does not require binary or proprietary parsers; and offers web-friendly compression options. Some compression methods would require a WASM decoder.
2. Other formats might be preferable for users to upload. In particular, OBJ, FBX, STL, and USDZ are common, but less ideal for rendering in a lightweight client.
3. I suspect the proposed model HTML element would be immensely helpful in reducing the security and performance footprint of this feature, compared to a WebGL library. The current state of the proposal focuses on support for USDZ and glTF models. If something were needed sooner, https://modelviewer.dev/ is comparable.

Disclaimer: I'm a maintainer of three.js and a contributor to the glTF file format specification.

gITF sounds fair to me. It is so common that this filetype is offered on different websites and is supported in several 3D software titles.

I tested it with a model of a wheel rim, it does work well. But it seems like the gITF file needs a dependent binary file, right?

Otherwise I think we can add this filetype to Commons, maybe with other filetypes later.

Greetings

There are two main container conventions for glTF files:

• .glb files are binary, and self-contained, with no external resources. The binary includes (1) a file header, (2) a JSON chunk describing the contents, and (3) a binary chunk containing data for geometry, textures, and perhaps animations.
• .gltf files are JSON, and typically contain references (by relative path) to one or more external resources. Those resources might include one or more .bin files with geometry and animation data, and images used for textures.

Those are conventions, not rules – it is possible to construct a .glb with external resources, or a .gltf without any. But I think it would be very reasonable to enforce a rule that users may upload only the .glb container, and that it cannot contain references to external resources. This is the most common use of the format.

Facebook previously supported uploading 3D models in posts, though they've since removed that feature. In case it's helpful as a reference, these were their rules and restrictions on user uploads:

• https://web.archive.org/web/20190903182539/https://developers.facebook.com/docs/sharing/3d-posts/asset-requirements
• https://web.archive.org/web/20190903221309/https://developers.facebook.com/docs/sharing/3d-posts/glb-tutorials

Summary:

• We support GLB files (GLB is the binary version of the glTF 2.0 file format).
• Your GLB must be under 3MB in total. The smaller the better.
• Strip out unused data whenever possible. Unused vertex colors, UV's, etc. all add to the file size.
• Use PNG or JPEG files for textures.
• Use JPEG files unless you need transparency. This will make your files much smaller.
• Textures must be power-of-2 in each dimension (512x1024 for example).
• Textures can be up to 4k, but try to keep them under 2k.
• Once you have a GLB file, you can just drag it into a new post, pick a background color and share it.
• The PBR shader can use these textures:
  • Base Color (rgba, with alpha optionally driving transparency)
  • Normal
  • Emissive
  • ORM (Packed into channels in a single texture: Red has the Occlusion texture, Green has the Roughness texture and Blue has the Metalness texture.)
• Additionally, the PBR shader will use vertex color, if present.

The power-of-two size requirement on textures is there to benefit low-end devices supporting WebGL 1.0 but not WebGL 2.0. Support for WebGL 2.0 is more common today than it was then, but still missing on 3-5% of devices according to different surveys:

• https://caniuse.com/webgl2
• https://web3dsurvey.com/webgl2

Not listed in formal requirements, models were also required to pass validation (excluding some low-severity hints) under the Khronos Group's official validation library.

Is the gITF format as such suitable to be implemented in Wikimedia Commons with its attributes as mentioned above? :)

What is the current state/progress? :)

@PantheraLeo1359531 See everything that is written in this task before

I’ll be blunt. No one is working on this, no one is planned to be working on this. There is no magic pixie dust to move it forward. It needs ppl spending time to program it and no one has volunteered to do so, so nothing will change until that changes.

Asking for what the progress is, is always completely useless, the ticket should and does reflect the state/progress accurately.

Maybe we can acquire one or more voluntary people?

Maybe it is a stupid question, but I want to figure out what we can achieve, because it would be a fantastic addition to Commons.

If you have the ability, feel free to volunteer :) [seriously, if anyone is interested and has some background knowledge in programming and wants to do this, we will provide advice and help]

If you want to recruit someone, probably better to look elsewhere, as everyone on this task is already aware of the request.

I am afraid, I can't, but I will keep my eyes open :)

Would be really nice if we can achieve this

The WMF agreed to do this in principle [so long as it did not use too much in the way of developer time] at the last Wikimania. Perhaps I should reach out to the WMF and remind them of this commitment?

I wrote a short report on my chat with the WMF at the Commons village pump which can be read here; https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2023/09#Enable_textured_3D_files_on_Commons

Please do!

I also asked some people if they know someone who could contribute.

In T246901#9226554, @brion wrote:

So if we add server-side rendering, we need a clean way to sandbox it, that works both in standalone installs and via Thumbor, and can be relatively sensibly managed and packaged, and made disableable with a switch-flip.

@Legoktm on SJ's computer here :) We can use Shellbox for sandboxing, which transparently handles standalone installs, but someone will need to do the Thumbor integration. I already ported all the deployed MediaHandlers to use Shellbox so there's plenty of examples from others to copy from!

@Discott

Did WMF answer already?

In T246901#9324384, @Sj wrote:

In T246901#9226554, @brion wrote:

So if we add server-side rendering, we need a clean way to sandbox it, that works both in standalone installs and via Thumbor, and can be relatively sensibly managed and packaged, and made disableable with a switch-flip.

@Legoktm on SJ's computer here :) We can use Shellbox for sandboxing, which transparently handles standalone installs, but someone will need to do the Thumbor integration. I already ported all the deployed MediaHandlers to use Shellbox so there's plenty of examples from others to copy from!

Hey, do you have an idea of how to progress this? It would be such a good addition and this is getting quite a vintage phab ticket. Is there a way to add it to someone's list of work at WMF to investigate further and plan the next steps?

Thanks

@brion what do you say?

In T246901#9394722, @Sj wrote:

@brion what do you say?

Probably the wrong account: @bvibber

Still waiting on WMF to budget time to look into doing more multimedia work. :)

Please note there is as far as I know no active Wikimedia-sponsored work at present on any multimedia file format support except for self-driven 20% time by me plus volunteer work by @TheDJ on TimedMediaHandler (audio/video playback).

Problem analysis has not changed since my initial reply years ago:

• use GLTF format for color models, it's standard and well supported
• update the frontend and the backend renderers
• if necessary, replace them with newer libraries

One additional thing: Safari has native USD model support, depending on whether there are format patent issues or not (needs investigation) it might be worth including support for native display via a conversion. This would be a stretch goal, potentially assignable via Mobile Apps if interested for iOS/iPad/Vision Pro compatibility.

(I see this is also in the Hackathon workboard -- perfect timing! I'll have updates on the patch for folks to test by then but I'll be remote for it. :D)

In T246901#9723607, @bvibber wrote:

Still waiting on WMF to budget time to look into doing more multimedia work. :)

Please note there is as far as I know no active Wikimedia-sponsored work at present on any multimedia file format support except for self-driven 20% time by me plus volunteer work by @TheDJ on TimedMediaHandler (audio/video playback).

I asked a staff member weeks ago and she said fiscal year ends at the end of June. Maybe then the budget can be used for the implementation, among others? :)

In T246901#9724027, @bvibber wrote:

(I see this is also in the Hackathon workboard -- perfect timing! I'll have updates on the patch for folks to test by then but I'll be remote for it. :D)

Is there any news after the Hackathon on this topic? :)

Hi @bvibber thanks so much for picking this up after 4 years, I'm not a wizard so I don't really understand your updates, but if there's anything muggles can do to help with this please let us know :) E.g I'd be happy to start a list of open license repositories for full colour 3d models

In T246901#9836182, @John_Cummings wrote:

Hi @bvibber thanks so much for picking this up after 4 years, I'm not a wizard so I don't really understand your updates, but if there's anything muggles can do to help with this please let us know :) E.g I'd be happy to start a list of open license repositories for full colour 3d models

There you go:

• Poly Haven: https://polyhaven.com/models
• AmbientCG: https://ambientcg.com/list?category=&date=&createdUsing=&basedOn=&q=&method=&type=3DModel&sort=Latest
• Sharetextures: https://www.sharetextures.com/models
• https://threedscans.com/
• https://3d.si.edu/cc0
• https://github.com/nasa/NASA-3D-Resources
• https://3d.nih.gov/entries/3DPX-016621 (example)
• Internet Archive(?)

:)

• https://www.esi.uclm.es/museo/index_en.html sounds also interesting

In T246901#9836655, @PantheraLeo1359531 wrote:

In T246901#9836182, @John_Cummings wrote:

Hi @bvibber thanks so much for picking this up after 4 years, I'm not a wizard so I don't really understand your updates, but if there's anything muggles can do to help with this please let us know :) E.g I'd be happy to start a list of open license repositories for full colour 3d models

There you go:

• Poly Haven: https://polyhaven.com/models
• AmbientCG: https://ambientcg.com/list?category=&date=&createdUsing=&basedOn=&q=&method=&type=3DModel&sort=Latest
• Sharetextures: https://www.sharetextures.com/models
• https://threedscans.com/
• https://3d.si.edu/cc0
• https://github.com/nasa/NASA-3D-Resources
• https://3d.nih.gov/entries/3DPX-016621 (example)
• Internet Archive(?)

:)

I can verify that Smithsonian 3D has been waiting a long time for Commons to support files that can do colors/textures

We at the Basque Wikimedians User Group are currently working on a GLAM project which may have content from museums currently available at SketchFab uploaded into Commons. It is known that this is currently impossible.

https://www.blender.org/download/demo-files/ also offers free *.blend files, where colored meshes can be exported

There's many further sources of 3D models with textures such as this. Also note that several STL files should probably get uploaded as a new version for the textured version (example). However, don't know why listing sources would help close the issue.

I found some sort of GLTF Viewer from the Poly Haven source code repository: https://github.com/Poly-Haven/polyhaven.com/tree/master/components/AssetPage/WebGL

Maybe this would help to implement relevant functions?

<hopeful>

Just look at this cc-by cast: https://sketchfab.com/3d-models/homo-neanderthalensis-skull-cast-a1ffe02b7e2f42ff972953484f3212d3

I have created a prototype for a viewer that also supports GLB files in the ‘mediawiki’ style. Only simple GLB files and KTX2 compression are supported. I am not yet satisfied with the positioning of the models, especially in view of the thumbnails. Help and feedback are very welcome.

You could choose from different free STL and GLB models, or upload your own data. Is KTX2 compression required?

Github Page: https://opendem.github.io/WikiMediaExtension3D_Test_GLB_Format/
Github: https://github.com/OpenDEM/WikiMediaExtension3D_Test_GLB_Format

It can take a while for the larger models to load, no ProgressBar is implemented here.

@OpenDEM

I just took a look at it, and this is already very good! Thank you very much for this :) (Color and shading make a huge difference)

As a feedback I suggest maybe adding key bindings, so this would make it easier to navigate (for beginners), and maybe stats like how many polygons or edges this model has

I uploaded a duck test files, works also fine. Maybe the zooming could be a bit smoother :)

Nice work, @OpenDEM! 😊

I think it’s important to understand why this is taking so long to improve. Here is some context on how we got here and some of the reasons:

• The Wikimedia Foundation has not allocated enough resources to improve this. As @bvibber stated: "Still waiting on WMF to budget time to look into doing more multimedia work. :)"
• This topic has not gained enough traction to be included in recent editions of the Community Wishlist. In November 2025 it will be 10 years since it was requested
• Upgrading these two repositories, 3d2png and 3D extension, is complex for non WMF technical staff. I'm not saying it can’t be done by volunteers, but it requires a certain degree of expertise in WMF's infrastructure.

I have also tried what seems to me the shortest path to get this done: updating the 3d2png Thumbor plugin and the 3D extension (with relative success), and I created this prototype of how a page with a 3D viewer could look. I would be happy to discuss and work together on this. You can join here to discuss it further.

Meanwhile, the 3D content market is consolidating. Epic Games has just launched fab.com (Sketchfab, ArtStation, Unreal Engine Marketplace, Quixel).
A public domain 3D content repository would be of immense value, and WMF should lead in this.

Having a list of 3D repositories is helpful, but I suggest we have a serious discussion about securing more WMF resources for this.

• Could someone submit a proposal to the Community Wishlist?
• What other ways might there be to secure more resources for development?

Hope this helps.

Thanks a lot @GabrielLucas for your enlightening background information and all the work! I will approach our local Wikipedia chapter next week and ask for support for the Wishlist.

Very important step :)
Let's make it happen

The current issues surrounding Sketchfab show how important a non-commercial platform for sharing and visualising textured 3D models would be. Click here for the petition with lots of background information: https://www.change.org/p/keep-sketchfab-alive-preserve-open-access-to-3d-art-museum-collections

We added a page on Commons to collect these kinds of examples and the general issue for a more non-technical audience, to not crowd this Phabricator task with usage examples. Please feel free to improve it ;)
https://commons.wikimedia.org/wiki/Commons:Textured_3D

In T246901#10283625, @OpenDEM wrote:

The current issues surrounding Sketchfab show how important a non-commercial platform for sharing and visualising textured 3D models would be. Click here for the petition with lots of background information: https://www.change.org/p/keep-sketchfab-alive-preserve-open-access-to-3d-art-museum-collections

Finally! :)

Back on the wish lists:

1. Technische Wünsche (the German original): https://de.wikipedia.org/wiki/Wikipedia:Technische_W%C3%BCnsche/Wunschparkplatz#Unterst%C3%BCtzung_texturierter_3D_Modelle
2. Community Wishlist: https://meta.wikimedia.org/wiki/Community_Wishlist - Not visible yet.

It has now worked on the third attempt: https://meta.wikimedia.org/wiki/Community_Wishlist/Wishes/Support_full_colour_3D_models_on_Wikimedia_projects

The Wikimedia Foundation will be hosting a series of community calls to help prioritize support efforts from Wikimedia Foundation for the 2025-2026 Fiscal Year.

The purpose of these calls is to support community members in hearing more from one another - across uploaders, moderators, GLAM enthusiasts, tool and bot makers, etc. - about the future of Commons. There is so much to discuss about the general direction of the project, and we hope that people from different perspectives can think through some of the tradeoffs that will shape Commons going forward.

Our first call will focus on Content Organization. It will take place at two different time slots:

• The first one will be on November 21, at 08:00 UTC, and it will be hosted on Zoom by Senior Director of Product Management Runa Bhattacharjee; you can subscribe to it on Meta;
• The second one will be on November 21, at 16:00 UTC, and it will be hosted on Zoom by Chief Product & Technology Officer Selena Deckelmann; you can subscribe to it on Meta.

If you cannot attend the meeting, you are invited to express your point of view at any time you want on the Commons community calls talk page. We will also post the notes of the meeting on the project page, to give the possibility to read what was discussed also to those who couldn’t attend it.

If you want, you are invited to share this invitation with all the people you think might be interested in this call.

Event:Commons community discussion - 21 November 2024 8:00 UTC

https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_December_2024

Sorry, the links got lost:

https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_21_November_2024_8:00_UTC
https://meta.wikimedia.org/wiki/Event:Commons_community_discussion_-_21_November_2024_16:00_UTC

Good opportunities to make our concerns heard. I hope to meet you there.

just a warm note to @OpenDEM @PantheraLeo1359531 and @GabrielLucas : thanks for the progress and keeping this thread live

Huge thanks from me, too :). Happy to see the project growing

As of today, it is possible to vote on ‘Technische_Wünsche_2024’ for a thematic focus (26.11.2024-9.12.2024). Please vote for 'COMMONS-ERSTELLEN' to bring our cause forward!
https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche_2024

I've added a few small changes to @OpenDEM's prototype viewer. The default centering/positioning of the 3D models should be more consistent now, but let us know if you find issues!

Would it be helpful to have a document somewhere, writing up requirements and/or best practices on the following considerations ...

• model orientation (which direction is up, forward)
• file size
• performance
• materials, textures, lighting, and appearance

... for artists and contributors trying to upload 3D models? And if so... what would be the best place to share that?

The focus area including this task / proposal is now open for voting along with a few other Commons-related areas: https://meta.wikimedia.org/wiki/Community_Wishlist/Focus_areas/Media_formats,_editing,_and_display

Hi @donmccurdy, @Prototyperspective,

I'm new to this community, previously Cultural Heritage Lead at sketchfab.com, currently a co-chair of the IIIF 3D Community Group, and very happy to learn about the conversation underway here about updating 3D support on Wikipedia/Wiki Commons.

I'm interested to know how best I might contribute insights from my experience to this conversation?

It feels like there is a lot of overlap with discussions we have had about 3D in the IIIF community, and I have a lot of more practical/anecdotal thoughts that I think/hope would be of value here. I've responded to the topics in the list Don shared below.

In T246901#10362412, @donmccurdy wrote:

I've added a few small changes to @OpenDEM's prototype viewer. The default centering/positioning of the 3D models should be more consistent now, but let us know if you find issues!

Would it be helpful to have a document somewhere, writing up requirements and/or best practices on the following considerations ...

• model orientation (which direction is up, forward)

For the in-development IIIF 3D spec, the group settled on positive y axis points upwards

• file size

This is generally subjective based on the subject and model type, but providing recommendations to uploaders is good idea e.g. "5mb total file size is great, 200mb is starting to exclude some audiences". It is also worth thinking about supporting a 'display model' and associated higher resolution 'downloadable versions'.

• performance

Can you elaborate on what you mean by this? Is there a min. standard for media performance on Wiki platforms?

• materials, textures, lighting, and appearance

Lots of considerations here, even for 'bare minimum' set up or recommendations. Over in the IIIF group we started with a set of user stories to help guide development, with the acknowledgement that the userbase of Wikipedia/Commons is much broader than 'cultural heritage' users.

... for artists and contributors trying to upload 3D models? And if so... what would be the best place to share that?

Hi @Nebulousflynn, nice to have you :). Afaik it is about the implementation of a 3D viewer for textured models and what "quality of life" features it should include, also while handling larger files.

I have added the current status of the ongoing work to the page https://commons.wikimedia.org/wiki/Commons:Textured_3D. Help is very welcome.