Extension talk:3D

Extension name

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Is "3d" sufficiently descriptive? I dunno, it seems fine to me but will our users (i.e. sysadmins etc.) agree? Jdforrester (WMF) (talk) 22:09, 7 April 2016 (UTC)

I don't know, I guess we'll find out! GDubuc (WMF) (talk) 22:39, 7 April 2016 (UTC)

:-) Jdforrester (WMF) (talk) 23:21, 7 April 2016 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Internal views of a 3d surface

It can support it if the relevant file formats are added (and pass security and performance reviews).

Would this extension support viewing the inside of a 3d surface?

To give an example, there has been interest in doing 3d scans of room where the internal surface is then known but the external surface isn't (or is at least not of interest). For these files to be useful on wiki you would have to be able to start on the inside of the surface looking outwards.

As a follow up: Does the extension allow moving the centre point about which one is viewing? André Costa (WMSE) (talk) 08:46, 15 July 2016 (UTC)

Do you have a sample AMF or STL file of a 3d room scan handy? I don't know how the normals values would be like for that kind of file, having a real example would allow me to check how the extension currently behaves.

The controls in the extension are a basic set taken from three.js examples, there's definitely room for debate about how it should exactly work. My latest experience with 3d software is dated and I don't know if there's any more consensus about that now than there was back when I used 3dsmax, blender and the like. I think there's plenty of opportunity to create a bunch of key-based shortcuts to do a variety of view-controlling things, it's just that I'd rather look into controls that are de-facto standards, if there are any. GDubuc (WMF) (talk) 08:02, 25 July 2016 (UTC)

I'll check with the person who has actually tested the equipment to see if he has a handy example file. Will get back to you on that.

As for controls I definitely agree that using standard ones is for the best. André Costa (WMSE) (talk) 09:08, 1 August 2016 (UTC)

Ok. It looks like there was some miscommunication between me and the person who had tested the equipment. The output for these seems to be an OBJ file rather than AMF or STL.

I have an example file for this if you think it might be of use, although I don't know enough about the file formats to say whether anything will be lost in a conversion to STL/AMF. André Costa (WMSE) (talk) 08:40, 9 August 2016 (UTC)

Yeah I don't know about conversion either, nor what information might be lost in it. We can give it a try, I think github has a viewer for 3d files based on the same library as my thing, at least we could compare the OBJ on github, the converted OBJ (probably to STL) on github and the converted OBJ in my extension. Just to check that it'll do at least as good a job as github, even if some information is lost in the conversion.

Textures will definitely be lost if OBJ supports them, AMF and STL and purely for geometry with at most plain color for vertices. I know that much. GDubuc (WMF) (talk) 08:00, 10 August 2016 (UTC)

Thanks for the clarification.

I did a quick conversion to STL and it looks like the information about which vertices should be transparent (from some angels) was lost (meaning you only see the external surface). I can provide you with a copy of the OBJ file but since it is of the flat of our contact and might include his kids in the background he asked that we didn't publish it openly for everyone.

As an aside are there any open formats which would also support textures? And if so do you know if there are any plans to support these (within MediaWiki)? André Costa (WMSE) (talk) 12:01, 12 August 2016 (UTC)

Obj would be a fine format to support in this extension, however I've avoided textured formats at first because they come with a new set of challenges. Mediawiki as it stands was designed for single file uploads (a file page is only ever about a single file), and often 3d formats that support reference to textures expect the textures as external files (eg. jpgs in addition to the obj). This makes it challenging in the context of Mediawiki, it would be quite a large undertaking to complete. It's definitely out of scope as a side project for me. I haven't heard of anyone trying to do this at the moment.

I think a better first step for texture support would be to find a format that supports embedded textures and support only that mode (not external files). That's more doable, but then it's kind of a big caveat if that 3d file format also supports external textures, it means that we wouldn't support all files of that type that people try to upload. Could come with a warning on upload, I guess, saying that only embedded textures are supported when references to external ones are found in the file. GDubuc (WMF) (talk) 07:01, 14 August 2016 (UTC)

Thanks for the update and the clarification around the issues with the obj format.

I agree that a single file solution would be both nicer and easier to support in the current framework. As for only supporting some of the files that people try to upload this sounds similar to what we already do with svg. I.e. we support embedded raster images but not externally linked ones. Not sure if we can detect and warn on upload though. But at the least if another format was supported with a similar limitation the community should be able to deal with it using similar methods to those employed today. André Costa (WMSE) (talk) 13:17, 21 September 2016 (UTC)

Interesting discussion. There seem to be a couple of formats supporting embedded textures and colors:

• glTF - supports a json containing an embedded 3d object containing textures (.gltf), along with a separate binary format (.glb) .
  • Try dragging this file (https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/1.0/Duck/glTF-Embedded/Duck.gltfor this (https://github.com/KhronosGroup/glTF-Sample-Models/tree/master/1.0/Duck/glTF-Binary) into https://www.virtualgis.io/gltfviewer/
• Threejs JSON - see [1]which seems to be supported by clara.io (https://clara.io/view/b8484920-bbda-436f-8813-734efc33d48b)

glTF looks especially promising because it will be natively supported by Windows 10, google chrome (http://www.phoronix.com/scan.php?page=news_item&px=Chrome-Adds-glTF-Parser) . So eventually it may eventually be possible to display directly using regular browsers without any need for javascript, and this will likely also go into android Chrome browser, and maybe opera too since it uses the same engine.This makes it an attractive format because it could be edited just like a normal page, and could maybe work in a similar manner to Help:Map_Data.

This format (glTF) goes far beyond simply showing the interior. It can also show animations. Try dragging and dropping these:

• https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/1.0/VC/glTF-Embedded/VC.gltf
• https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/1.0/CesiumMan/glTF-Binary/CesiumMan.glb

Into this:

https://sandbox.babylonjs.com/ 197.218.81.3 (talk) 12:49, 7 May 2017 (UTC)

I cant download the extension

To make it simple, i cant download the extension the usualway of downloading extensions. zomewhere i must login or register LDAP. What is that and why so diffilcut procedure/way Gharryh (talk) 10:35, 12 January 2017 (UTC)

If you don't have git available, my only suggestion is to just manually create the file structure and copy and paste the source. If you'd like, I can prepare a zip file for you. James Martindale (talk) 00:13, 13 January 2017 (UTC)

Yes please if possible Gharryh (talk) 16:41, 2 February 2017 (UTC)

https://jkmartindale.com/miscellaneous/3d.zip James Martindale (talk) 03:31, 3 February 2017 (UTC)

Suggestion: Consider supporting .glTF as an upload format

Perhaps later "once there are robust, standard ways to security-vet user-generated-content".

Apparently, glTF is the new up and coming 3d "standard" format, that will (probably) be available by default on android OS, Windows 10, and other devices:

• http://architosh.com/2017/01/khronos-places-opengl-and-opengl-es-conformance-tests-into-open-source/
• https://blogs.windows.com/buildingapps/2016/10/28/bringing-3d-to-everyone-through-open-standards/#pVIRe2avp0ujtpXm.97
• http://www.roadtovr.com/call-vr-open-standard-backed-valve-oculus-google-osvr/
• http://www.businesswire.com/news/home/20151019005826/en/Khronos-Finalizes-glTF-1.0-Specification-Efficient-Interoperable

It might be useful to research how easy (or hard) it is to integrate it into this extension. 197.218.89.191 (talk) 14:16, 5 February 2017 (UTC)

It is very unlikely that in the next year or so we'd add support for file formats other than basic 3D shapes given the security problems. Once there are robust, standard ways to security-vet user-generated-content, we can reconsider that. Jdforrester (WMF) (talk) 16:45, 6 February 2017 (UTC)

That's understandable, although it is less likely that there are serious security risk with this particular format because it mainly uses a combination of json, binary files, text, and images to store its contents according to, either separately or combined in a single format :

https://www.khronos.org/gltf

It is also already supported by the software behind this extension, three.js:

https://github.com/KhronosGroup/glTF/tree/master/loaders/threejs

Anyway, it makes perfect sense to avoid scope creep in the initial version, although it is something to keep in mind in the futur. For reference here's a demo:

https://threejs.org/examples/webgl_loader_gltf.html

Thanks for the clearing that up! 197.218.89.52 (talk) 17:53, 6 February 2017 (UTC)

Suggestion: Look into using 3d fingerprinting as a deterrent against duplicates and copyright infringement

One major issues with 3d formats is that some lack metadata unlike other media that provides metadata such as image width, height and duration. The regular sha1 check will be essentially useless because even minute differences can change the sha1. So the fact that there is no metadata for the .stl format seems to be a problem.

One only moderately feasible solution might be fingerprinting:

http://dl.acm.org/citation.cfm?id=2687511.2687545

http://ieeexplore.ieee.org/abstract/document/7103711/ 197.218.90.59 (talk) 19:15, 9 March 2017 (UTC)

Rather than "moderately feasible" I'd say "infeasible", sadly. Jdforrester (WMF) (talk) 19:50, 9 March 2017 (UTC)

How so?

Do you mean that it will be expensive (both technically and economically) to process and generate these?

It may well be depending on how popular this format becomes on wikimedia wikis. One potential solution might be to generate the "perceptual hash" or fingerprint of the thumbnail (this extension already generates) rather than the whole 3d object. This is certainly "eventually" feasible as even can imagemagik or elasticsearch can generate these and can handle more than a million files:

• Hacking Elasticsearch for Image Retrieval - https://www.linkedin.com/pulse/hacking-elasticsearch-image-retrieval-ashwin-saval?articleId=8828975402389796690 https://github.com/kzwang/elasticsearch-image
• https://www.imagemagick.org/script/compare.php

If all else fails, maybe at least creating an extra sha1. One for the whole file (as is probably the current case), and one for the thumbnail. That way if the file extension matches and the sha1 is the same the duplicate detection at least more chances of preventing (or later detecting) re-uploads.

The point remains that there is still a need for some extra data to guard against misuse, and potentially improve its usability. 197.218.90.59 (talk) 20:20, 9 March 2017 (UTC)

Both of the links you provided are to academic papers suggesting how someone might write some software. For us to reasonably put this feature into the extension, let alone use it in Wikimedia production, it would need to be implemented in a highly-scalable widely-used open source tool that we could re-use after careful architecture, performance, and security reviews. ImageMagick is used right now, but AIUI doesn't implement this (and thus won't in Debian stable for years).

In practical terms, that's pretty infeasible. :-( Jdforrester (WMF) (talk) 22:39, 9 March 2017 (UTC)

You're quite right about no support for 3d files in imagemagick, and there don't seem to be easy to find implementations of 3d hashing algorithms. However, the alternative suggestion would still work.

The imagemagick version wikimedia is currently running does support generating hashes from images. Long ago I tried to compare several simple images with imagemagick and it works much better than a simple sha1 check. So it is entirely possible to generate an image fingerprint hash for the png file created by this extension:

http://www.fmwconcepts.com/imagemagick/phashconvert/index.php

http://www.fmwconcepts.com/misc_tests/perceptual_hash_test_results_510/index.html

It is not as good as having a proper hash for the whole file, but it may serve as a reasonable fallback.

I do understand that this may still not be feasible due to the way the database is currently structured. Especially when one considers that the new hash would need to be stored somewhere, and that it is not compatible with the existing one. 197.218.90.59 (talk) 00:01, 10 March 2017 (UTC)

There is also a popular library in node (only for image hash):

https://github.com/aaronm67/node-phash 197.218.90.59 (talk) 00:51, 10 March 2017 (UTC)

Suggestion: Perhaps it is time to reconsider the image table schema (get rid of enum)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

It seems that an earlier database design decision has just come back to bite this extension. Currently the only way to add a new mime type is to do a schema change in the image table. This seems to be a technical debt that will keep coming back, e.g. Extension:MolHandler, [1], [2].

The older mime type addition hasn't even made it to WMF wikis after more than 2 years despite being part of mediawiki core. This would be trivial to simply add this to a separate reference table as a new row without any schema changes.

It is highly unlikely that this will be done in the short term, but it seems like something to consider for the long term (maybe with a phabricator task of its own).

See also:

http://komlenic.com/244/8-reasons-why-mysqls-enum-data-type-is-evil/ 197.218.81.5 (talk) 15:47, 15 March 2017 (UTC)

Seems to have been partly considered :

https://phabricator.wikimedia.org/T157348 197.218.81.5 (talk) 16:13, 15 March 2017 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Suggestion: Make the 3d object interactive on pages ( or at least on the file page)

Issue:

It is currently not possible to zoom in, rotate, move or otherwise interact with the object unless multimedia viewer is loaded.

Background

While it is understandable that the 3d file shouldn't automatically fully load because these can be prohibitively large, it would be useful to at least have a click to interact functionality (similar to graphs or maps). If it isn't currently feasible on the article pages, it could at least work in file pages.

It also becomes cumbersome if someone has a lot of small 3d files to have to go back and forth in the 3d viewer, rather than simply interact directly on a page.

Proposed solution

The 3d extension adopts a mechanism similar to the Extension:StlHandler which does allow interaction in the file page. Although it probably needs a click to interact functionality to avoid taking time to open file pages which would probably be off-putting to editors.

Side note: The funny thing is that now the multimedia viewer currently does something that the file page cannot, while historically it has been the opposite, e.g. ironically the multimedia viewer can't play videos or audio. 197.218.88.97 (talk) 07:06, 28 April 2017 (UTC)

Hello 197, I appreciate the suggestion. I've created a Phab task for the team to discuss. CKoerner (WMF) (talk) 15:13, 3 May 2017 (UTC)

Suggestion: Adapt extension to render chemical files (e.g. pdb)

Issue

It is not currently possible to illustrate chemical files in wiki pages without cumbersome processes (e.g. create externally, change to image and upload).

Background

This seems to be a useful feature according to these:

• https://phabricator.wikimedia.org/T18491(Extension:Jmol)
  • Extension:MolHandler
• https://phabricator.wikimedia.org/T46660

Proposed solution

Evaluate existing libraries that extend three.js

• https://github.com/3dmol
• http://paulbacchus.com/mollyjs-a-webgl-molecule-viewer/
• https://github.com/grahamgilchrist/threejs-molecule-test
• https://github.com/biochem-fan/GLmol

Use existing loader

• https://threejs.org/docs/#examples/loaders/PDBLoader

Evaluate existing implementation in existing extension (Extension:PDBHandler).

Demo:

https://threejs.org/examples/css3d_molecules.html

Extension:PDBhandler in action:

• http://bsd.neuroinf.jp/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:3h9v.pdb(http://web.archive.org/web/20170430144452/http://bsd.neuroinf.jp/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:3h9v.pdb)

• http://bsd.neuroinf.jp/wiki/P2X%E5%8F%97%E5%AE%B9%E4%BD%93

Notes: currently pdbhandler seems to work in file pages and article pages, so it actually works better than extension:3d for now, probably because on average they are likely to be smaller than a normal 3d file. 197.218.91.245 (talk) 14:50, 30 April 2017 (UTC)

Another demo of pdb in action :

https://threejs.org/examples/webgl_loader_pdb.html 197.218.91.245 (talk) 15:00, 30 April 2017 (UTC)

I bet there's some folks from WikiProject Chemistry who would love this feature as well. :)

There's a few phab tasks related to this request. I've added a note to them.

https://phabricator.wikimedia.org/T7535

https://phabricator.wikimedia.org/T18491

Thank you again for the thoughtful suggestion. They are often informative and you're always kind in presenting them. CKoerner (WMF) (talk) 15:22, 3 May 2017 (UTC)

> Thank you again for the thoughtful suggestion. 

You're welcome. 197.218.91.186 (talk) 19:20, 4 May 2017 (UTC)

Suggestion: An option to continuously rotate the object

Problem

Users may not be aware that the image can be interacted without appropriate controls.

Background

Rotating an image automatically allows one to view it literally from another perspective. This is something that is currently impossible with most other video formats and should be taken advantage of.

Proposed ideas

• Add a new wikitext construct to 3d files, .e.g [[file:abc.png|rotate=true]]
• Add a keyboard shortcut to initiate and stop rotation (see Extension:StlHandler)
• Add a button to the Multimedia viewer to initiate and stop rotation.
• Add some help info indicating what can be done with the object. 197.218.90.233 (talk) 17:47, 2 May 2017 (UTC)

Oops, Extension:3DAlloy is the one with the automatic rotation. 197.218.90.233 (talk) 17:58, 2 May 2017 (UTC)

Another suggestion, another phab task! :)

https://phabricator.wikimedia.org/T164383 CKoerner (WMF) (talk) 15:43, 3 May 2017 (UTC)

Issue: Pressing keyboard arrows (right or left) while viewing 3d objects rotates the object and loads another file / image

Fixed

Problem

The current keyboard arrows seem to rotate the 3d object and also change the viewed image to the next or previous image

Steps to reproduce

1. Go to https://commons.wikimedia.beta.wmflabs.org/wiki/3d
2. Click one of the files in the gallery
3. Press the right arrow (->) in the keyboard
4. Press the left arrow (<-) in the keyboard

Expected

• Load the previous or next file

Actual

The multimedia viewer loads first rotates the 3d object, then loads a new file

It also adds this note in the browser console (if arrows are pressed repeatedly):

"WARNING: Too many active WebGL contexts. Oldest context will be lost."

Proposed solutions

1. Make sure that the object can only be rotated using a modifier key (e.g. ctrl + ->).
2. Don't load too many 3d objects in memory, this may slow down the browser or crash it.

Notes

This seems to suspend the loading of the current 3d object, only to continue later, and may sometimes refuse to load if this is repeated too many times. 197.218.91.186 (talk) 18:53, 4 May 2017 (UTC)

For integrity and your information:

https://phabricator.wikimedia.org/T164565 - Arrow keys for rotating models interfer with navigation in gallery #Reaper (talk) 21:30, 5 May 2017 (UTC)

Issue: Multimedia viewer automatically loads big (> 2MB) 3d files

Problem

3d file loads twice, it loads thumbnail and then the stl file which can take considerable time with huge files (potentially a Gigabyte).

Background

This breaks the expectation that one will quickly move through all files because it may take much more time to fully load the 3d object. This would be a bit like loading a thumbnail for a video in the file page and then loading all of the video (think ~4 GB, e.g File:Kašelj - Rudnik via Orle.webm) itself without any user interaction (an anti-feature of many sites). This considerably consumes user bandwidth.

Proposed solutions

1. Click to load the 3d object;
2. Only load the 3d object automatically if it is smaller than X KB (e.g. less than 2000 KB); or
3. A toggle option in the 3d viewer to automatically load 3d files (disabled by default) - useful for galleries of small 3d files

Notes

This seems like a critical issue that should be resolved before the extension leaves beta or is deployed anywhere, as it will adversely affect user experience. 197.218.91.186 (talk) 19:19, 4 May 2017 (UTC)

Not exactly the same but an similar "problem" I suggested too:

https://phabricator.wikimedia.org/T164544 - Add "Level of Detail" (LoD) implementation for 3D files

That might "fix" the problem you mentioned indirectly (but will also end up in an discussion which size of file is reasonable for users and hardware, anyway). #Reaper (talk) 21:35, 5 May 2017 (UTC)

Interesting idea, and yes it would fully resolve the issue if it also allows clicking to fully load the file.

There doesn't need to be much of a discussion about the right file size. Wikis have metrics about their multimedia usage, and the minimum supported browser requires specific hardware. In fact, some videos may be slow or unbearable in older computers, and yet they are still uploaded. 3d animated content has also existed since MS-DOS times, so most devices have supported lower quality 3d for more than a decade. The problem here is wasting people's bandwidth (and possibly crashing their browsers) without them being aware of it.

It may be slower but smaller files will likely still render in reasonably old devices. 197.218.92.133 (talk) 11:49, 6 May 2017 (UTC)

Yes, full file should definitely be available - but we need an warning too, as we already have for large images.

Yes, some high definition videos (or even 4k+) dont work on older PCs but we already got the resolution chooser there, too. 3D files are more compareable to image files. As they get too big, the device might get out of memory or just can't handle the file properly / getting too slow. As for example files created using photogrammetry can get easily 1mio+ polygons. That's handle-able even for older PCs, but I think it's not for many mobile devices (but older ones don't support WebGL, but only afaik). And yes, I agree with the bandwidth issue. #Reaper (talk) 21:29, 6 May 2017 (UTC)

Alternate 3D formats

First off, this is awesome!

In case there is discussion about adding additional 3D solid model formats, IGES and STEP are fairly common Bryandamon (talk) 21:24, 10 November 2017 (UTC)

Cannot upload stl files to my mediawiki

anyone else get this?

I also can no longer view my uploaded files either

[Wk7RM63suHYAAEKEgBkAAAAA] /index.php?title=Special:Upload TypeError from line 164 of /home/username/sample.com/includes/shell/Command.php: Argument 1 passed to MediaWiki\Shell\Command::environment() must be of the type array, null given, called in /home/username/sample.com/includes/GlobalFunctions.php on line 2303

Backtrace:

#0 /home/username/sample.com/includes/GlobalFunctions.php(2303): MediaWiki\Shell\Command->environment(NULL)

#1 /home/username/sample.com/includes/GlobalFunctions.php(2337): wfShellExec(string, string, NULL, array, array)

#2 /home/username/sample.com/extensions/3D/ThreeDHandler.php(108): wfShellExecWithStderr(string, string, NULL, array)

#3 /home/username/sample.com/includes/filerepo/file/File.php(1141): MediaWiki\Extensions\ThreeD\ThreeDHandler->doTransform(LocalFile, string, string, array)

#4 /home/username/sample.com/includes/filerepo/file/File.php(1104): File->generateAndSaveThumb(TempFSFile, array, integer)

#5 /home/username/sample.com/includes/gallery/TraditionalImageGallery.php(125): File->transform(array)

#6 /home/username/sample.com/includes/specials/SpecialUpload.php(830): TraditionalImageGallery->toHTML()

#7 /home/username/sample.com/includes/specials/SpecialUpload.php(427): SpecialUpload->getDupeWarning(array)

#8 /home/username/sample.com/includes/specials/SpecialUpload.php(524): SpecialUpload->showUploadWarning(array)

#9 /home/username/sample.com/includes/specials/SpecialUpload.php(207): SpecialUpload->processUpload()

#10 /home/username/sample.com/includes/specialpage/SpecialPage.php(522): SpecialUpload->execute(NULL)

#11 /home/username/sample.com/includes/specialpage/SpecialPageFactory.php(578): SpecialPage->run(NULL)

#12 /home/username/sample.com/includes/MediaWiki.php(287): SpecialPageFactory::executePath(Title, RequestContext)

#13 /home/username/sample.com/includes/MediaWiki.php(851): MediaWiki->performRequest()

#14 /home/username/sample.com/includes/MediaWiki.php(523): MediaWiki->main()

#15 /home/username/sample.com/index.php(43): MediaWiki->run()

#16 {main} 2600:1700:E4A0:7CC0:4D1B:CE0C:2AFF:A8F1 (talk) 01:17, 5 January 2018 (UTC)

IP, could you share what release of MediaWiki and the 3D extension you're using? CKoerner (WMF) (talk) 22:35, 18 January 2018 (UTC)

I get the same with current git master. Brooke Vibber (WMF) (talk) 16:11, 21 February 2018 (UTC)

$wg3dProcessEnviron is never defined, so it's NULL instead of an array. Brooke Vibber (WMF) (talk) 16:14, 21 February 2018 (UTC)

To work around: manually set $wg3dProcessEnviron = []; in LocalSettings.php Brooke Vibber (WMF) (talk) 16:16, 21 February 2018 (UTC)

reported as https://phabricator.wikimedia.org/T187902 Brooke Vibber (WMF) (talk) 16:18, 21 February 2018 (UTC)

Error Creating Thumbnail

Hi all,

Having to jump through a lot of hoops to get this to work.. I'm hoping someone can help with this.

Error creating thumbnail: module.js:545 throw err; ^ Error: Cannot find module 'gl' at Function.Module._resolveFilename (module.js:543:15) at Function.Module._load (module.js:470:25) at Module.require (module.js:593:17) at require (internal/module.js:11:18) at Object.<anonymous> (/home/o2et2hhr3b2m/public_html/extensions/3d2png/3d2png.js:5:7) at Module._compile (module.js:649:30) at Object.Module._extensions..js (module.js:660:10) at Module.load (module.js:561:32) at tryModuleLoad (module.js:501:12) at Function.Module._load (module.js:493:3)

I've been trying to install module gj but i then get this error message

npm install --save  gl

> gl@4.0.3 install /home/o2et2hhr3b2m/public_html/extensions/3d2png/node_modules/gl

> prebuild --install

prebuild info begin Prebuild version 5.1.2

prebuild info looking for local prebuild @ prebuilds/gl-v4.0.3-node-v59-linux-x64.tar.gz

prebuild info looking for cached prebuild @ /root/.npm/_prebuilds/https-github.com-stackgl-headless-gl-releases-download-v4.0.3-gl-v4.0.3-node-v59-linux-x64.tar.gz

prebuild http request GET https://github.com/stackgl/headless-gl/releases/download/v4.0.3/gl-v4.0.3-node-v59-linux-x64.tar.gz

prebuild http 404 https://github.com/stackgl/headless-gl/releases/download/v4.0.3/gl-v4.0.3-node-v59-linux-x64.tar.gz

prebuild WARN install No prebuilt binaries found (target=9.8.0 runtime=node arch=x64 platform=linux)

prebuild info install We will now try to compile from source.

make: Entering directory `/home/o2et2hhr3b2m/public_html/extensions/3d2png/node_modules/gl/build'

  CXX(target) Release/obj.target/angle_common/angle/src/common/Float16ToFloat32.o

In file included from ../angle/src/common/debug.h:16,

                 from ../angle/src/common/mathutil.h:12,

                 from ../angle/src/common/Float16ToFloat32.cpp:9:

../angle/src/common/angleutils.h: In function ‘void SafeDeleteContainer(T&)’:

../angle/src/common/angleutils.h:74: error: expected initializer before ‘:’ token

../angle/src/common/angleutils.h:79: error: expected primary-expression before ‘}’ token

../angle/src/common/angleutils.h:79: error: expected ‘)’ before ‘}’ token

../angle/src/common/angleutils.h:79: error: expected primary-expression before ‘}’ token

../angle/src/common/angleutils.h:79: error: expected ‘;’ before ‘}’ token

In file included from ../angle/src/common/Float16ToFloat32.cpp:9:

../angle/src/common/mathutil.h: In constructor ‘gl::IndexRange::IndexRange()’:

../angle/src/common/mathutil.h:563: error: type ‘gl::IndexRange’ is not a direct base of ‘gl::IndexRange’

make: *** [Release/obj.target/angle_common/angle/src/common/Float16ToFloat32.o] Error 1

make: Leaving directory `/home/o2et2hhr3b2m/public_html/extensions/3d2png/node_modules/gl/build'

prebuild ERR! build error

prebuild ERR! stack Error: `make` failed with exit code: 2

prebuild ERR! stack     at ChildProcess.onExit (/home/o2et2hhr3b2m/public_html/extensions/3d2png/node_modules/node-gyp/lib/build.js:258:23)

prebuild ERR! stack     at ChildProcess.emit (events.js:180:13)

prebuild ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)

prebuild ERR! not ok

prebuild ERR! build Error: `make` failed with exit code: 2

prebuild ERR! build     at ChildProcess.onExit (/home/o2et2hhr3b2m/public_html/extensions/3d2png/node_modules/node-gyp/lib/build.js:258:23)

prebuild ERR! build     at ChildProcess.emit (events.js:180:13)

prebuild ERR! build     at Process.ChildProcess._handle.onexit (internal/child_process.js:209:12)

npm ERR! code ELIFECYCLE

npm ERR! errno 2

npm ERR! gl@4.0.3 install: `prebuild --install`

npm ERR! Exit status 2

npm ERR!

npm ERR! Failed at the gl@4.0.3 install script.

npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

npm ERR!     /root/.npm/_logs/2018-03-14T22_37_47_559Z-debug.log Stationeers.Wiki (talk) 22:38, 14 March 2018 (UTC)

It might have something to do with the dependencies of gl:

sudo apt-get install -y build-essential libxi-dev libglu1-mesa-dev libglew-dev

https://www.npmjs.com/package/gl 152.7.255.196 (talk) 12:54, 25 April 2018 (UTC)

Invalid ELF header while creating thumbnail

Error creating thumbnail: /var/lib/mediawiki/3d2png/node_modules/bindings/bindings.js:88 throw e ^ Error: /var/lib/mediawiki/3d2png/node_modules/gl/build/Release/webgl.node: invalid ELF header at Object.Module._extensions..node (internal/modules/cjs/loader.js:683:18) at Module.load (internal/modules/cjs/loader.js:566:32) at tryModuleLoad (internal/modules/cjs/loader.js:506:12) at Function.Module._load (internal/modules/cjs/loader.js:498:3) at Module.require (internal/modules/cjs/loader.js:598:17) at require (internal/modules/cjs/helpers.js:11:18) at bindings (/var/lib/mediawiki/3d2png/node_modules/bindings/bindings.js:81:44) at Object.<anonymous> (/var/lib/mediawiki/3d2png/node_modules/gl/webgl.js:4:35) at Module._compile (internal/modules/cjs/loader.js:654:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:665:10)rom

From what I can tell, this means that something is compiled for a different platform for the STL upload. I'm on Debian jessie, and mediawiki 1.31 . Any and all help would be appreciated, thanks! 152.7.255.195 (talk) 12:40, 25 April 2018 (UTC)

Set thumbnail/initial view orientation

Is there a way to set the initial view orientation for each file? I uploaded this file [3] and default view looks on the rear side of this object. Thanks for hints! -- Xorx (talk) 15:06, 11 November 2020 (UTC)

Unable to interact with 3D models

Not sure where it was best to post this, but I also created a Phabricator task: https://phabricator.wikimedia.org/T268807

All the configuration required for the extension has been done, but interacting with 3D models seems to not be possible via MediaViewer. I'm not sure what the cause of this could be or how to debug? Expected behaviour: https://test.wikipedia.org/wiki/File:Programmatically_created_crystal.stl#/media/File:Programmatically_created_crystal.stl Behaviour: https://funkey.miraheze.org/wiki/File:FunKey_Button_Cover_3D_Model.STL Reception123 (talk) 09:07, 26 November 2020 (UTC)

Nobody using Windows?

How to use 3d2png in Windows? It only wrote, for Linux blah blah... 2409:891F:82A3:88AC:F5BE:F874:CF43:12EF (talk) 03:25, 9 September 2022 (UTC)

Textures? Commons info page?

Will it become possible to upload 3D models including textures? I don't know why it's currently not possible – are there already plans for enabling that?

Why is there no info page on Wikimedia Commons about 3D models like STL files? For asking about this, I only found Commons:Category talk:3D models. It would be good to have a place with some info on what, how, and so on.

For example, I found this page useful to convert CCBY models on sketchfab to STL files that can be uploaded to WMC. They lose their textures when doing so. I think 3D models could be useful for many purposes, and probably also for generative AI that can be used to create images of any kind like Stable Diffusion. They would benefit from getting trained on categorized 3D models. Prototyperspective (talk) 11:17, 20 November 2023 (UTC)

I've responded on the duplicated discussion you started on Commons:Category talk:3D models. Waldyrious (talk) 00:15, 23 November 2023 (UTC)