On Mar 22, 2014 6:50 PM, "Bryan Davis" <[email protected]> wrote: > > On Fri, Mar 21, 2014 at 1:27 AM, Umang Sharma <[email protected]> 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 <[email protected]> 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 <[email protected]> > [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA > irc: bd808 v:415.839.6885 x6855 > > _______________________________________________ > Multimedia mailing list > [email protected] > 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
_______________________________________________ Multimedia mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/multimedia
