On Mar 22, 2014 6:50 PM, "Bryan Davis" <bd808(a)wikimedia.org> wrote:
On Fri, Mar 21, 2014 at 1:27 AM, Umang Sharma <umange(a)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(a)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/na…
[2]:
http://www.web3d.org/x3d/content/examples/Conformance/BindableNodes/Viewpoi…
[3]:
http://www.web3d.org/files/specifications/19775-1/V3.3/Part01/components/te…
--
Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org>
[[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA
irc: bd808 v:415.839.6885 x6855
_______________________________________________
Multimedia mailing list
Multimedia(a)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