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/components/navigation.html#Viewpoint
> [2]: http://www.web3d.org/x3d/content/examples/Conformance/BindableNodes/Viewpoint/_pages/page06.html
> [3]: http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/texturing.html#ImageTexture
> --
> Bryan Davis Wikimedia Foundation <bd808@wikimedia.org>
> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
> irc: bd808 v:415.839.6885 x6855
>
> _______________________________________________
> Multimedia mailing list
> Multimedia@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/multimedia
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