Extension talk:3D

Jump to navigation Jump to search

About this board

Stationeers.Wiki (talkcontribs)

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! 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 (talkcontribs)

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


Reply to "Error Creating Thumbnail"

Invalid ELF header while creating thumbnail

1 (talkcontribs)

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!

Reply to "Invalid ELF header while creating thumbnail"

Cannot upload stl files to my mediawiki

2600:1700:E4A0:7CC0:4D1B:CE0C:2AFF:A8F1 (talkcontribs)

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


#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}

CKoerner (WMF) (talkcontribs)

IP, could you share what release of MediaWiki and the 3D extension you're using?

Brion Vibber (WMF) (talkcontribs)

I get the same with current git master.

Brion Vibber (WMF) (talkcontribs)

$wg3dProcessEnviron is never defined, so it's NULL instead of an array.

Brion Vibber (WMF) (talkcontribs)

To work around: manually set $wg3dProcessEnviron = []; in LocalSettings.php

Brion Vibber (WMF) (talkcontribs)
Reply to "Cannot upload stl files to my mediawiki"
Bryandamon (talkcontribs)

First off, this is awesome!

In case there is discussion about adding additional 3D solid model formats, IGES and STEP are fairly common

Reply to "Alternate 3D formats"

Internal views of a 3d surface

Summary by

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

André Costa (WMSE) (talkcontribs)

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?

GDubuc (WMF) (talkcontribs)

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.

André Costa (WMSE) (talkcontribs)

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) (talkcontribs)

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.

GDubuc (WMF) (talkcontribs)

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.

André Costa (WMSE) (talkcontribs)

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)?

GDubuc (WMF) (talkcontribs)

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.

André Costa (WMSE) (talkcontribs)

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. (talkcontribs)

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

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:

Into this:


Reply to "Internal views of a 3d surface"

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

4 (talkcontribs)


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


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


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.

Reaper35 (talkcontribs)

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). (talkcontribs)

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.

Reaper35 (talkcontribs)

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.

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

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

Summary by

Fixed (talkcontribs)


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


  • Load the previous or next file


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.


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.

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

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

4 (talkcontribs)


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


This seems to be a useful feature according to these:

Proposed solution

Evaluate existing libraries that extend three.js

Use existing loader

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



Extension:PDBhandler in action:

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. (talkcontribs)
CKoerner (WMF) (talkcontribs) (talkcontribs)

> Thank you again for the thoughtful suggestion. 

You're welcome.

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

Suggestion: An option to continuously rotate the object

3 (talkcontribs)


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


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. (talkcontribs)
CKoerner (WMF) (talkcontribs)
Reply to "Suggestion: An option to continuously rotate the object"

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

2 (talkcontribs)


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


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.

CKoerner (WMF) (talkcontribs)

Hello 197, I appreciate the suggestion. I've created a Phab task for the team to discuss.

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