When looking at the current versions of the code:

• https://gerrit.wikimedia.org/r/plugins/gitiles/3d2png/+/refs/heads/master/3d2png.js
• https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/3D/+/refs/heads/master/modules/mmv.3d.js

the first thing that strikes me is that 3d2png.js and mmv3d.js use completely different intensities for the lights they place in the scene.

• 3d2png:

this.camera.add( new THREE.PointLight( 0xffffff, 0.3 ) );
this.scene.add( new THREE.AmbientLight( 0x666666, 0.5 ) );
light = new THREE.SpotLight( 0x999999, 1 );

• mmv3d.js:

const headlight = new THREE.PointLight( 0xffffff, 150 );
this.scene.add( new THREE.AmbientLight( 0x666666, 2 ) );
const light = new THREE.SpotLight( 0x999999, 100000 );

The point light in mmv3d is 500 times brighter than that in 3d2png, the ambient light 4 times, and the spot light a whopping 100,000 times. What is the reason for these enormous differences?

Screenshot when rendering https://commons.wikimedia.org/wiki/File:Sphericon.stl:

Screenshot when rendering https://commons.wikimedia.org/wiki/File:Wikipedia_puzzle_globe_3D_render.stl:

In T416723#11592464, @Carsten_Steger wrote:

The point light in mmv3d is 500 times brighter than that in 3d2png, the ambient light 4 times, and the spot light a whopping 100,000 times. What is the reason for these enormous differences?

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/3D/+blame/refs/heads/master/modules/mmv.3d.js

https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/3D/+/54757bc7cbb55bebe596f02bbf306d3cbe11d014 - 2024

https://gerrit.wikimedia.org/r/plugins/gitiles/3d2png/+blame/refs/heads/master/3d2png.js

https://gerrit.wikimedia.org/r/plugins/gitiles/3d2png/+/55c253d65596dafea73a66d9e35dcfe88195a18f - 2017

Please excuse me for asking what probably is a newbie question: is there a way to test the 3D extension (and any modifications I would like to test) in a standalone manner locally in a browser without having to install a large amount of software?

One observation: when I rotate https://commons.wikimedia.org/wiki/File:Menger_sponge_2.stl in such a way that one of the cube faces is parallel to the image plane, one can see a little bit of shading on the faces that are parallel to the viewing direction. This would indicate to me that the headlight is much too bright.

Another observation: the bounding box of https://commons.wikimedia.org/wiki/File:Sphericon.stl is [-1000:1000]³. I have not found that the geometry is scaled in any way after it has been loaded. Could one of the reasons for the fact that this model seems to be displayed only with the ambient illumination be that the spot light lies within the object?
const light = new THREE.SpotLight( 0x999999, 100000 );
light.position.set( -100, 50, 25 );
Could another reason be that the headlight is too far away from the object and is therefore attenuated to almost 0?

@Carsten_Steger You could use this viewer for testing: https://github.com/OpenDEM/WikiMediaExtension3D_Test_GLB_Format

The problem is that the standard lighting system from Three.js is not used here. This differs greatly from previous versions and does not look quite as good for STL files. You can test this here: https://opendem.github.io/WikiMediaExtension3D_Test_GLB_Format/ The adjustments made by the WMF have now resulted in some models no longer displaying at all.

Change #1247633 had a related patch set uploaded (by Dmaza; author: Dmaza):

[mediawiki/extensions/3D@master] [WIP]

https://gerrit.wikimedia.org/r/1247633

@dmaza Thank you very much for your patch! I would love to test it, but don't know how I could do that. In any event, the code changes in your patch look very good to me. I have one suggestion that could be added to the patch because of your changes. Currently, mmv.3d.js contains the following call (line 45 with your patch applied):
this.camera = new THREE.PerspectiveCamera( 60, dimensions.ratio, 0.001, 500000 );
The huge z range of 0.001 to 500000 leads to a very inefficient use of the precision of the depth buffer. Since your patch scales the models to a much smaller depth range, at least the far value of 500000 of the frustum could be drastically reduced, which should result in better quality depth rendering.

In T416723#11683067, @Carsten_Steger wrote:

@dmaza Thank you very much for your patch! I would love to test it, but don't know how I could do that. In any event, the code changes in your patch look very good to me. I have one suggestion that could be added to the patch because of your changes. Currently, mmv.3d.js contains the following call (line 45 with your patch applied):
this.camera = new THREE.PerspectiveCamera( 60, dimensions.ratio, 0.001, 500000 );
The huge z range of 0.001 to 500000 leads to a very inefficient use of the precision of the depth buffer. Since your patch scales the models to a much smaller depth range, at least the far value of 500000 of the frustum could be drastically reduced, which should result in better quality depth rendering.

Thank you for pointing that out. I've adjusted the far/near plane to more sensible defaults. I did see some z-fighting/actifacts in some models like this https://commons.wikimedia.org/wiki/File:Massospondylus_skull_BP-1-5241_3D_scan.stl#/media/File:Massospondylus_skull_BP-1-5241_3D_scan.stl but I wasn't sure what was causing it. It looks like this was the issue

As far as testing the changes, unfortunately the only way is to install a local copy of mediawiki and the 3D extension with it's dependencies.

As far as testing the changes, unfortunately the only way is to install a local copy of mediawiki and the 3D extension with it's dependencies.

@Carsten_Steger That's exactly why we created a simple HTML/JS Testviewer. I've added the latest adjustments here: https://opendem.github.io/WikiMediaExtension3D_Test_GLB_Format/stl_test_3_2026.html

The code is available on Github: https://github.com/OpenDEM/WikiMediaExtension3D_Test_GLB_Format
No build is necessary, only a local web server due to CORS issues.
I have added another critical .stl model.

@dmaza If you have time, please take a look at the code to see if I have taken all changes into account correctly. Visually, it looks the same, as far as I can tell.

Wouldn't patch demo also be an option to test this?

Does this also work with external thumbnailers such as 3d2png?

Hmm, good question — I don't know. I just thought I'd mention it because it wasn't referred previously. :)

@OpenDEM Thank you for the link to https://opendem.github.io/WikiMediaExtension3D_Test_GLB_Format/stl_test_3_2026.html and for integrating the code changes there! I uploaded and tested my model 5-Cell_Schlegel_Diagram.stl there. The lighting much better with the code changes and my model is displayed correctly. Therefore, thank you all very much for the effort you have put into this patch!

When browsing through the predefined models on the above link, I noted that the brightness could be increased a little bit. The brightest gray values I got were around 210, so it seems that the brightness of the lights could be increased by 15-20%. This might create a more vivid impression of the models.

Also, what confused me at first is that the lights are attached to the scene, so the lighting remains static when you turn the object. Based on the interaction with the object that the MMV provides, my mental model was that I turn the object in front of my eye. Therefore, I would have expected the light sources to remain stationary relative to my view position. However, the mental model that seems to be behind the model is that you walk around the object, in which case the light position would remain stationary. This model wasn't the most intuitive to me. I know that the current lighting model is completely valid, too, so which one to might be a matter of preference.

One drawback of attaching the light to the scene might be that the orientation in which the model is defined in the STL file determines which parts are lit. For example, in the STL Ganesha Cologne Zoo file on the above link, the rear part of the statue is illuminated while the front part is partly in the shadows. This might make the interpretation of the 3D model somewhat more difficult and it somewhat obscures the more important part of the model. A similar problem occurs for the STL Lion Cologne Zoo model: its head is in the shadow. Mightn't it be better to attach the light sources to the camera instead of the scene instead to avoid this kind of behavior?