Extension talk:3D

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.

I've responded on the duplicated discussion you started on Commons:Category talk:3D models.

How to use 3d2png in Windows? It only wrote, for Linux blah blah...

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

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

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?

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.

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.

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.

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.

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

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.

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.

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/

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

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

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!

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}

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

I get the same with current git master.

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

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

reported as https://phabricator.wikimedia.org/T187902

First off, this is awesome!

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

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.

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

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.

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.