I agree with Bryan that this would need to be handled on the client side at upload time. Basically upload a 3d model, each texture is displayed for entering licensing information, then everything is uploaded by the client (there might be issues with CORS there if we want to avoid the server ever downloading arbitrary URLS), and the XML image references are updated to point to textures we host. Or they're converted to data URIs. While that later option is simpler for us, it also means that a model would take longer to display at all. External references allow you to display a model untextured at first, while the textures are downloaded by the client. With data: URIs you lose that benefit.

With the upcoming major work we're about to embark on regarding UploadWizard and the upload pipeline, I think that this project, which is so unlike the existing upload flow, would be badly timed. If written based on the existing UploadWizard, it will be very unlikely to be merged back by the time we've cleaned up or rewritten UW entirely.

I also think that there might be too many big problems with major decisions for it to be suitable for GSOC. Complex issues both on the frontend and the backend. Unless we consider that anything that gets built will only be useful for improving our common knowledge of the format for a future real integration, knowing that anything that gets built by Umang won't be merged. Is it useful to do what is essentially a throwaway project, though? I'm not sure how to even scope it in that context.

Maybe the project would be to support viewing as many 3d formats as possible on the file page using JS, in a reusable fashion that could later be integrated into Media Viewer. The upload pipeline would be totally ignored, meaning that this work wouldn't get merged, but would be useful whenever we embark on making 3d model upload possible. Maybe it's too thin a project, though, as most of the code would be already written as 3rd-party 3d model viewers.

On Sunday, March 23, 2014, Brian Wolff <bawolff@gmail.com> wrote:

On Mar 22, 2014 6:50 PM, "Bryan Davis" <bd808@wikimedia.org> wrote:
>
> On Fri, Mar 21, 2014 at 1:27 AM, Umang Sharma <umange@gmail.com> wrote:
> >
> > The X3D format provides an XML code as an source code. This XML script can
> > be used to extract information of the file. There are functions like
> > getScreenshot() which return a .png file of the 3D image. There are also
> > functions to manipulate the camera views (given in the API documentation of
> > x3d). Using these views we can set a standard view and use the
> > getScreenshot() function to get a .png file.
> > How getScreenshot() actually works is :
> > " getScreenshot()
> > Returns:    URL to image
> > Returns a Base64 encoded data URI containing png image consisting of the
> > current rendering. The browser will interpret this as a PNG image and
> > display it. A list of browsers which support data URI can be found here. The
> > following example illustrates the usage:
> >     var url = ...runtime.getScreenshot();
> >     var img = document.createElement("img");
> >     img.src = url;
> >     ...
> > "
> > This is taken from the documentation of x3d.
>
> This seems to be a quote from the documentation for the X3DOM runtime
> api. X3DOM is a javascript library for browser-based display and
> manipulation of x3d content. It's not obvious to me by reading the
> documentation for X3DOM [0] that this library would be in any way
> useful for creating raster images from x3d files server-side.
>
> On Thu, Mar 20, 2014 at 4:26 AM, Gilles Dubuc <gilles@wikimedia.org> wrote:
> >
> > - Do X3D and COLLADA files always contain camera information? If they only
> > contain the geometry (and textures?) of the models, then we're probably
> > going to have an issue with picking a default camera position.
>
> The X3d spec defines a Viewpoint [1] node that can be used to provide
> a camera position. It seems that the conformance tests also expect
> that the default viewpoint for models which do not define one is (0 0
> 10) [2].
>
> > Also, another question that needs to be answered is whether textures are
> > embedded in these files or if they are referenced. If they are referenced
> > instead of being embedded, then texture support in itself would be a complex
> > matter (how would people upload the images needed as textures?), and your
> > proposal makes no mention of it at the moment.
>
> ImageTexture nodes define a url field [3] specifying the image to
> download and apply. This does complicate the server side processing
> quite a bit. We almost certainly wouldn't want to download the texture
> images in response to the need to generate a thumbnail. Downloading
> images to the servers could be done at upload time as a job similar to
> the way that GWToolset downloads images based on a bulk specification
> file. There are problems with this however including the fact that
> only a limited number of external domains are whitelisted for
> downloading. Things get even more complicated due to the MovieTexture
> node that can be used to bind MPEG1-Video as the texture for a
> surface.
>
> The inclusion of external content as textures seems to also raise a
> potential privacy concern for allowing users to view the x3d content
> directly in their browser via X3DOM or other javascript/HTML5
> rendering techniques. If the textures are drawn from sources outside
> of commons and/or the bits servers it would be possible to effectively
> track the viewers of the models ala the classic single pixel
> advertising tracking bug. This becomes even more troubling if one
> imagines allowing embedding a x3d directly in an article page which
> could allow tracking viewers of that article. This leads me to believe
> that we would have to import all texture files to commons and rewrite
> the model to reference content from there rather than an external
> host.
>
> [0]: http://x3dom.org/docs/dev/
> [1]: http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/co

We could maybe make it data: urls allowed only like we do with svgs.

As for movie textures - that seems like a big bag of worms. If that feature isnt commonly used, maybe we should just disallow files using it.

--
Bawolff