Last modified: 2014-10-28 12:47:28 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 http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro . Perhaps create a new type, instead of just Images and Sound, add Source Files, or maybe Sources? Thank you for considering this. spiderworm
*** This bug has been marked as a duplicate of 898 ***
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: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Use_of_COLLADA_format_to_enable_3D_models_for_exemplification.2C_explanation.2C_and_illustration Michael Tiemann
Permanent link for the link in comment 2: <http://en.wikipedia.org/w/index.php?oldid=78488537#Use_of_COLLADA_format_to_enable_3D_models_for_exemplification.2C_explanation.2C_and_illustration> Updated bug summary as well.
Has there been any progress with this ? I would like to submit a model to Wikimedia Commons converted from the official NASA ISS model ( http://www.nasa.gov/multimedia/3d_resources/assets/iss-hi-res.html ) as I think it should be available to everyone. X3D is another alternative, but Collada may work as well.
There's been no active work on this in a while.
OK. Does it need a way to preview the Collada files ? Maybe I could find a solution.
(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.
There is a Sourceforge project ... http://sourceforge.net/projects/colladarefinery/files/ ( linked from the Khronos site http://www.khronos.org/collada/ ) There is a linux binary there ready to download .. "coherency test". The source code must there as well.
Suggest that x3d is considered as well, as suggested in comment #4. It is open and well standardized by now. Specs are available here: http://www.web3d.org/x3d/specifications/x3d/
Good info on the .blend file format. http://www.blender.org/development/architecture/blender-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.
*** Bug 29645 has been marked as a duplicate of this bug. ***
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 http://www.x3dom.org 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).
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.
This is not dependent on #17012 why should it?
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?
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.
There is http://www.mediawiki.org/wiki/Extension:X3d but no idea about maintenance and code quality. Testing and reviewing is probably welcome as a first step.
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 http://www.x3dom.org/ 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.
This feature request is being proposed at http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Add_support_for_x3d_3D_files_to_MediaWiki and I'm considering whether to add it or not to https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas Question: 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.
As far as I understand it there is some work already done on 3d support by wikipedia user:EMW http://www.mediawiki.org/wiki/Extension:PDBHandler 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? https://developer.mozilla.org/en-US/demos/detail/opendepth-point-cloud%20%20 http://code.google.com/p/open-3d-viewer/
Thanks for the pointer, I have left a comment at EMW's talk page: http://en.wikipedia.org/wiki/User_talk:Emw#Support_for_3D_files_and_Google_Summer_of_Code 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.
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.
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.
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.
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 http://caniuse.com/webgl. 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: http://weblog.benjaminsommer.com/blog/2012/05/13/comparison-of-webgl-framework-apis-part-5/. Three.js seems drastically more popular than X3DOM. Comparing some rough metrics of developer interest: GitHub: - https://github.com/x3dom/x3dom: 91 stars, 27 fork, 0 pull requests, 32 issues - https://github.com/mrdoob/three.js: 10,494 stars, 1,979 fork, 26 pull requests, 248 issues Stackoverflow: - 25 questions tagged for http://stackoverflow.com/questions/tagged/x3dom - 1,543 tagged questions for http://stackoverflow.com/questions/tagged/three.js IRC: - 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): http://www.amazon.com/WebGL-Up-Running-Tony-Parisi/dp/144932357X. I'm not aware of any books about X3DOM. The PDBHandler extension I've been working on also uses Three.js.
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.
Daniel, I was responding to comment 18, which says "I think that the x3dom system http://www.x3dom.org/ 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.
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.
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").
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 http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#New_media_types_supported_in_Commons The next stops in the mentored/paid calendar are the Wikimedia Individual Engagement Grants https://meta.wikimedia.org/wiki/Grants:IEG and the next OPW round, both pointing at the end of the year.
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.
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)?
This proposal is now featured at https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7
(In reply to comment #33) > This proposal is now featured at > https://www.mediawiki.org/wiki/Outreach_Program_for_Women/Round_7 Someone with more knowledge of the requirements should make a standalone page for this.
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 : https://www.mediawiki.org/wiki/User:Umang13/Gsoc14
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!
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.
(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).
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.
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.
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?
> 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 :)
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.
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)
So we agree on getting rid of "Blender" in the bug title?
