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 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: