Last modified: 2014-10-28 12:47:28 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3790, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1790 - Allow uploading of 3D files to Wikimedia Commons
Allow uploading of 3D files to Wikimedia Commons
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
All All
: Low enhancement with 11 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 29645 (view as bug list)
Depends on: 43616 52655
Blocks: multimedia
  Show dependency treegraph
Reported: 2005-03-31 14:46 UTC by David Millet
Modified: 2014-10-28 12:47 UTC (History)
27 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description David Millet 2005-03-31 14:46:59 UTC
Please allow registered users to upload .blend files to the commons.  I would
like to start a repository of Blender 3D resources including .blend files for
public use and for use with certain Blender 3D wiki projects, such as .

Perhaps create a new type, instead of just Images and Sound, add Source Files,
or maybe Sources?

Thank you for considering this.

Comment 1 Ævar Arnfjörð Bjarmason 2005-05-14 17:12:35 UTC

*** This bug has been marked as a duplicate of 898 ***
Comment 2 Michael Tiemann 2006-09-26 17:54:07 UTC
According to Ton Rosendaal (blender creator), the .blend file is actually not a
great format for containing 3d info--it contains a lot more that one doesn't
want.  Instead he suggests, and I proposed to the WP:VP that we use the COLLADA
3D format.  The proposal is here:

Michael Tiemann
Comment 4 Barney Holmes 2009-03-24 01:34:59 UTC
Has there been any progress with this ? I would like to submit a model to Wikimedia Commons converted from the official NASA ISS model ( ) as I think it should be available to everyone. X3D is another alternative, but Collada may work as well.
Comment 5 Brion Vibber 2009-03-24 17:50:40 UTC
There's been no active work on this in a while. 
Comment 6 Barney Holmes 2009-03-24 18:25:02 UTC
OK. Does it need a way to preview the Collada files ? Maybe I could find a solution.
Comment 7 Mike.lifeguard 2009-08-21 00:35:57 UTC
(In reply to comment #6)
> OK. Does it need a way to preview the Collada files ? Maybe I could find a
> solution.

That's be nice, but serving thumbs isn't strictly necessary. The more important thing is a way to verify the file is safe to have on the server, I think.
Comment 8 Barney Holmes 2009-08-21 12:27:14 UTC
There is a Sourceforge project ...

( linked from the Khronos site )

There is a linux binary there ready to download .. "coherency test". The source code must there as well.

Comment 9 Amit Aronovitch 2009-11-01 19:26:58 UTC
Suggest that x3d is considered as well, as suggested in comment #4. It is open and well standardized by now.
Specs are available here:
Comment 10 Derk-Jan Hartman 2010-11-27 14:04:01 UTC
Good info on the .blend file format.

Should be easy to allow that for upload. It will indeed be very verbose, and as a "end product" file it is similar to uploading a Photoshop file with all intermediary steps and layers. Collada would be more like a jpg file in that comparison.
Comment 11 ralf 2011-06-30 06:45:18 UTC
*** Bug 29645 has been marked as a duplicate of this bug. ***
Comment 12 ralf 2011-06-30 06:58:57 UTC
In favor of X3d, there exists in all major browsers either native support or 3rd-party plugins to display X3D content. To include rudimentary but sufficient functionality for encyclopedic presentation purposes, and to open no
security holes it suffices to define a HTML header and footer framing an actual filename in the x3d format, and to define a restricted subset of the x3d format that will be understood.

Example HTML code working in all major browsers NOW can be found at

The HTML frame should ensure the 3d object can be rotated and zoomed with a mouse, which is the basic functionality needed by an encyclopedia atm.

Providing a 3D description of a 3D object is even more accessible (in the Accessibility sense) than an arbitrary 2D perspective of that object, even if there exist atm no way of presenting 3D objects to eg blind people (which I doubt).
Comment 13 ralf 2011-06-30 07:06:05 UTC
Oh and a further advantage of X3D against Collada is that X3D has support in molecular presentation software like VMD, where Collada is unknown. Face it, support of Collada is restricted to the rendering community, while X3D should be known everywhere.
Comment 14 ralf 2012-02-19 07:31:43 UTC
This is not dependent on #17012 why should it?
Comment 15 Jean-Fred 2012-12-14 15:20:28 UTC
What is blocking here?

* A sanitizer to detect malicious code in the X3D file at upload time?
* A MediaWiki-integrated fallback mode?
* Both/other? 
* Does the large browser support for X3D help or not really?
Comment 16 SJ 2012-12-15 02:28:55 UTC
I can't find any descriptions online of the scale and severity of "malicious embedded stuff" problems with various data formats.  How did we choose the formats that we don't support, back in the day?  

There should probably be a page on Commons dealing in detail with each class of knowledge or data-format, and the problems that need to be overcome before we can host such knowledge or formats.  

I don't actually know of a reason why we don't simply turn on uploading of a bunch of these formats, considering their ubiquity in other data- and file-sharing formats online; all we are doing is making it difficult for people to find and share freely-licensed knowledge in those formats, not making it difficult for someone with ill intent to share malicious hidden code.
Comment 17 Andre Klapper 2012-12-15 12:58:55 UTC
There is but no idea about maintenance and code quality. Testing and reviewing is probably welcome as a first step.
Comment 18 Tpt 2012-12-30 21:31:32 UTC
Extension:X3d is based on a Java applet that can output subset of x3d and its development looks stopped. So I don't think that this extension is the "ready out of the box" solution we are looking for.

I think that the x3dom system to output 3d files on wikis is the best possible choice because:
- x3d is an open standard well documented.
- most of 3d software can output in x3d.
- x3dom it's an active project with, I believe, a growing community.
- x3dom provide two fallback modes if the browser doesn't support x3d. The first one that is based on webGL and the second one based on flash.
- Extension:X3d doesn't support all x3d features.
Comment 19 Quim Gil 2013-03-23 18:00:42 UTC
This feature request is being proposed at

and I'm considering whether to add it or not to


Is there a potential mentor willing to help potential students interested in this project?

Is there a reasonable support from the Commons community to incorporate this feature if it's developed and meets the quality criteria?

Without these qualifications in place we can't even consider the proposal for GSOC 2013.
Comment 20 mrjohncummings 2013-03-24 19:19:55 UTC
As far as I understand it there is some work already done on 3d support by wikipedia user:EMW

I personally think 3d models would make such an excellent edition to Mediawiki, especially with sites like thingiverse which have many thousands of files that have a compatible license and free photogrammetry tools available. 

I have no programming ability but would be happy to ask around for some community support etc.

There are some projects that may be useful?
Comment 21 Quim Gil 2013-03-24 20:05:06 UTC
Thanks for the pointer, I have left a comment at EMW's talk page:

Please do ask around. I think we have enough consensus about seeing progress in this area. We could scope the GSOC project to the development of the extension. If it's good then the Commons community will evaluate it but we don't need to tie both things. Looks like a feature that makes sense and would be beneficial on 3rd party MediaWikis as well.
Comment 22 Jean-Fred 2013-03-25 15:38:20 UTC
I can say that interest for 3D rendering has regularly been voiced on Commons. 

If you need more direct input from the Commons community (a straw poll on a statement of interest, a list of potential use cases), please let us know and we’ll see what we can do.
Comment 23 Quim Gil 2013-03-25 15:57:19 UTC
The interest + no-opposition is indeed clear. I checked the Commons Village Pump and I saw several discussions, one of them happening these days. 

All we need now is at least one mentor.
Comment 24 mrjohncummings 2013-03-25 16:43:53 UTC
Any ideas where a mentor could be found? Happy to ask around but not sure I know anyone who could be a mentor for this.
Comment 25 Emw 2013-03-26 03:37:45 UTC
I've been working on a solution to do enable browser-native, interactive 3D models of proteins and DNA through the PDBHandler extension I've been developing. Here are some thoughts on possible high-level requirements for a potential GSoC project to enable broader support for interactive 3D models in Wikimedia projects:

The solution should use WebGL by default.  It probably isn't worth mentioning, but the solution should not use Java applets or Flash.

There needs to be a fallback for browsers that don't have WebGL enabled by default.  Many browsers don't support it, or only partially support it: see  IE10 and below don't support WebGL, and I would surprised if IE11 will.  WebGL is disabled by default in Safari 5.1 and 6.0, so Safari can effectively be considered to not support it.

The fallback should support rendering to the 3D model as a static image.  This is needed to support printing articles with 3D models, and would be a reasonable fallback for browsers that don't have WebGL enabled.  

Regarding the WebGL framework used, I'd be interested to learn more about how X3DOM compares to Three.js.  A brief comparison is here:

Three.js seems drastically more popular than X3DOM.  Comparing some rough metrics of developer interest:

- 91 stars,  27 fork, 0 pull requests, 32 issues
- 10,494  stars,  1,979 fork, 26 pull requests, 248 issues

- 25 questions tagged for
- 1,543 tagged questions for

- 0 users on irc://freenode/x3dom (Googling gave no relevant results for 'x3dom irc')
- 82 users on irc://freenode/three.js

There's also an O'Reilly book on Three.js (masquerading as a book on WebGL):  I'm not aware of any books about X3DOM.

The PDBHandler extension I've been working on also uses Three.js.
Comment 26 Daniel Friesen 2013-03-26 04:19:49 UTC
Emw, Three.js vs. x3dom is irrelevant to uploads.

X3DOM's popularity is irrelevant. What's being talked about is not X3DOM, it's the .x3d file format. Which can be exported by whatever 3d tools people are using and uploaded.

x3dom is primarily a viewer for .x3d files.

While Three.js is a library layer that allows you to write interactive 3d things in the browser. While it supports importing COLLADA it's not a viewer. You'd have to write your own viewer.

Apples and oranges.
Comment 27 Emw 2013-03-27 00:48:10 UTC
Daniel, I was responding to comment 18, which says "I think that the x3dom system to output 3d files on wikis
is the best possible choice".  It'd probably make sense to track in its own ticket, but a rendering system (which would presumably include some WebGL framework) seems important to consider when thinking about how Commons might handle 3D media files.
Comment 28 CMBJ 2013-06-07 05:40:37 UTC
I'd like to suggest that this bug's importance be changed to high enhancement - it's blocking a great deal of content across multiple areas in multiple projects.
Comment 29 Andre Klapper 2013-06-07 10:05:56 UTC
See comment 20 and comment 21 for how to help getting this request going. If somebody is really actively working on this, feel free to increase the priority to normal. However, fixing this is currently not considered urgent ("high").
Comment 30 Quim Gil 2013-06-07 16:54:06 UTC
An update on mentorship projects: even if this request was featured in our pages for Google Summer of Code and FOSS Outreach Program for Women (OPW) and we had potential mentors for it, nobody stepped in.

It's still a featured project at

The next stops in the mentored/paid calendar are the Wikimedia Individual Engagement Grants and the next OPW round, both pointing at the end of the year.
Comment 31 Greg Grossmeier 2013-08-08 16:45:16 UTC
To make it more clear what is going on, I've opened bug 52655, which is "Add support for thumbnails and interactive views of 3D models", ie: the technical ability of MediaWiki to do something meaningful with the files once they are uploaded.

This bug is now a tracking bug for enabling the feature (once ready, no ETA at all) on WMF wikis.
Comment 32 Nemo 2013-09-17 08:27:10 UTC
Do we have a wiki page summarising the status of this discussion/wishlist, other than the strategywiki proposal I'm now adding in URL (and related ones in the same category)?
Comment 33 Quim Gil 2013-10-30 21:55:23 UTC
This proposal is now featured at
Comment 34 Greg Grossmeier 2013-10-31 17:08:53 UTC
(In reply to comment #33)
> This proposal is now featured at

Someone with more knowledge of the requirements should make a standalone page for this.
Comment 35 Umang 2014-03-20 06:29:06 UTC
This project has been a long standing community request and it would be great if I were given the opportunity to work on this and make some progress. I have planned a basic outline on how to approach the problem. I have decided to provide a solution for either x3d or collada file formats(required for representing computer graphics). I will work on the other if time is there during my project. The plan I have proposed is to implement a solution on similar lines as media wiki normally represents files by rendering it into a .png file generating thumbnails by extracting meta data from image. I have talked a bit about this to the only mentor (Bryan Davis) listed on the website where this project was proposed. It would be great if some more interested people have a look at my idea. Furthermore, I would like feedback on which file format is more in demand currently(x3d or collada?). Also, if anyone has any recommendations for efficient raster image generations do tell. Please go through my proposal and tell me how can I improve it and make it up to the expectations of the community.

Link :
Comment 36 Quim Gil 2014-03-20 14:16:56 UTC
Hi Umang, my very suimple feedback is: make sure you don't miss the GSoC 2014 application deadline (tomorrow). We will have some extra days to discuss your proposal after that, but if you miss the deadline in Google Melange, Google will make no exceptions.

Thank you for your interest in contributing to Wikimedia, and thank you also for your willingness to solve a #1*** Bugzilla report!
Comment 37 Quim Gil 2014-03-25 14:39:37 UTC
This functionality was featured as a Wikimedia GSoC 2014 project idea, and Umang responded to it. He is doing his homework, but he need mentors to evaluate his proposal and, eventually, form a team to complete this task.

Bryan Davis is offering help as secondary mentor, but he is already primary mentor for another project. Can someone volunteer, please?

First things first, and the first thing is Umang's evaluation. Could you point to annoying litle bugs or other bug reports that he could work on to show off his skills? Thank you.

PS: also wondering, is it worth to contact the Blender team to see whether they would like to (co-)mentor? The Blender Foundation is also participating in GSoC 2014. I have no idea about this feature and its relation to Blender, but here is the thought.
Comment 38 Bawolff (Brian Wolff) 2014-03-25 15:16:52 UTC
(In reply to Quim Gil from comment #37)
> First things first, and the first thing is Umang's evaluation. Could you
> point to annoying litle bugs or other bug reports that he could work on to
> show off his skills? Thank you.

One possible task (this is a bit harder then most easy bugs, but only one i could think of off the top of my head) is to change max size handling code. Currently it is in the validateParam method. Instead max Size should be returned from its own method in MediaHandler, which should be checked from File::doTransform.

This way it would be cleaner to override, could be discarded for instant commons, and could have its own error message instead of the current useless generic one.

Other possibly easy bugs: gwtoolset blacklist to strict, gwtoolset doesnt normalize unicode (run Utf::cleanUp() on input from xml file)

All these have bug numbers, but not sure atm.

> PS: also wondering, is it worth to contact the Blender team to see whether
> they would like to (co-)mentor? The Blender Foundation is also participating
> in GSoC 2014. I have no idea about this feature and its relation to Blender,
> but here is the thought.

Its looks like it wont even be blenders format.

Personally this seems about as much to do with blender as say our png thumbnailing code has to do with gimp (that is just very tagentially).
Comment 39 Bawolff (Brian Wolff) 2014-03-25 20:53:44 UTC
To clarify (sorry for not doing so originally, i was in a rush), first issue is a combination of bug 62306 and bug 32387. This is currently assigned to gilles (which i didnt realize when mentioning it), so he might already be working on it (or might not, its been assigned for a while. Would have to ask him). Note that bug isnt that hard to code once you know what to do (although still a bit harder than average "easy" bug), but its not immediatly obvious what needs to be done. Anyways what im trying to say is if you want to tackle that bug, youre almost certainly going to need to ask for guidance, so dont be afraid to.

The other two are a bit simpler albeit not as closely related to your project. You may want to start trying with them They are bug 62909 and bug 62870. The hardest part of those bugs will probably be actually testing gwtoolset to see if your change worked, and dealing with the somewhat different coding conventions the extension uses.

Sorry i cant think of any simpler open multimedia related bugs.

Actually super simple open bug you could do - new special page that was just added named Special:ListDuplicateFiles uses the wfMessage() function where it should use $this->msg( ...) instead. Thats not all that related to your project, but it is multimedia related and should be an easy first commit.
Comment 40 Gilles Dubuc 2014-03-26 10:43:50 UTC
I'm not working on those bugs at the moment, the upcoming April 12th launch of Media Viewer is keeping us extremely busy. Once that's out of the way we'll start working on other projects, particularly Upload Wizard and the upload pipeline in general.
Comment 41 Jean-Fred 2014-09-03 08:58:22 UTC
I was reviewing [[COM:UNSUPPORTED]] earlier, to check if there were bugs opened for every needed feature.

Is this bug about 3D support in general, or a specific file format in particular? Shall I open a bug for, say, AMF support, or shall we consider this is covered by the general topic of this bug?
Comment 42 Jean-Fred 2014-09-23 12:45:57 UTC
> Is this bug about 3D support in general, or a specific file format in
> particular? Shall I open a bug for, say, AMF support, or shall we consider
> this is covered by the general topic of this bug?

Up-ing this :)
Comment 43 Marco 2014-09-23 20:55:11 UTC
Having a quick look at the comments suggests that this should be considered a tracking bug covering the 3D support in general.

Also, it is probably more clear to separate each request related to 3D support into a new bug report.
Comment 44 Bawolff (Brian Wolff) 2014-09-23 21:40:24 UTC
Well in theory they should be separate, in practise i doubt it would do much good unless someone was specificly comitted to implementing some format (splitting conversations rarely serves to attract more people in my experiance)
Comment 45 Marco 2014-09-25 21:59:01 UTC
So we agree on getting rid of "Blender" in the bug title?

Note You need to log in before you can comment on or make changes to this bug.