Hi Gilles,
Thank you for having a look into my proposal and giving your valuable
feedback. The proposal I sent was a brief outline of my project. I kept it
short as I have been advised to do so. I have given answers to some of your
queries with respect to the .x3d format below.
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.
Now, to texture. Every x3d file has a texture map. This map contains
Background, ImageTexture, MovieTexture, MultiTexture, and PixelTexture. In
all cases, texture maps are defined by 2D images that contain an array of
colour values describing the texture. If we want detailled texture we can
rebuild the texture using this map. The only problem I see here is that
this process might not be feasible in terms of memory and speed. Maybe it
will work out. Otherwise I believe even the screenshot will retain some
texture and we can use that as well. The good thing here is that the
texture map provided by x3d has a format in terms of PNG pixels which shall
make compatibility easy.
Some more details on texture maps :
Texture maps are defined in a 2D coordinate system (s, t) that ranges from
[0.0, 1.0] in both directions. The bottom edge of the image corresponds to
the S-axis of the texture map, and left edge of the image corresponds to
the T-axis of the texture map. The lower-left pixel of the image
corresponds to s=0, t=0, and the top-right pixel of the image corresponds
to s=1, t=1. Texture maps may be viewed as two dimensional colour functions
that, given an (s, t) coordinate, return a colour value colour(s, t).
I have not studied COLLADA in much depth and will get back to you on it in
some time. For the moment the advantages of using x3d seem to be :
-> First of all x3d seems to be pretty well documented and shall be easy to
go in even further depth.
-> All x3d files have a source code in xml which I have no problems with.
->Further, since we can get all contents of the file in xml it shall be
easy to validate it as well.
-> Functions like getScreenShot() should make our process comparitively
easy.
->Also, x3d files have meta statements. These meta statements provide
information of the x3d scene as a whole. We can directly take this
information from these meta statements.
Another thing that I found which might be relevant could be -
"*Blender export* :
Converting Blender scenes into X3DOM webpages is pretty simple: Blender
already supports direct X3D export even so there are some issues. Blender
Version 2.4 seems to export some more nodes (e.g. lights), but in general
it works. We will explore this more in the future, but an exported X3D file
( may afterwards be easily be integrated into an HTML webpage using X3DOM.
Just finish your model in Blender and export to x3d file format.
There are two ways to get your X3D data into the HTML page, and both
include no coding at all:
1. Two-file solution, link the X3D-file
Just use a very simple X3D scene in your HTML file, which, more or less,
only includes an <inline> node. This nodes references and asynchronously
downloads the X3D file. Therefore you need a real web server (e.g. Apache)
running while using <inline> nodes in X3DOM.
2. One-file solution, embed the X3D data inside of the HTML page
You can embed the X3D file by hand in a (X)HTML page, but this may include
some hand-tweaking. Better use the aopt-converter described in Generic 3D
data conversion. This can be done offline with a single command:
aopt -i horse.x3d -N horse.html (horse.x3d is an x3d file being converted
into an html one)
You also may use the converter online. Just open horse.x3d with your
favorite text editor and paste it into the source text field. Choose XML
encoding (X3D) as input type and HTML5 encoded webpage as output type and
press the Convert encoding button."
Even though I am more sure about the former method, I am mentioning this
here as there was some discussion on the bug related to blender files. If
this works then using x3d we can incorporate blender files as well.
I would be highly grateful if you could provide me with further insights
into this project.
Regards,
Umang
