[Fiware-miwi] XML3D pointers

[Kristian Sons]

Hi,

I guess Philipp has indicated most of this in his mails over the 
weekend. Anyway, in a compressed form all the stuff that we discussed 
last Friday:

* Meshes
There is no notion of a submesh in XML3D. In classical scene graphs a 
submesh is a mesh plus a shader and the mesh shares data with other 
submeshes from the same mesh. This is easy mappable to XML3D: A <group> 
+ <mesh> is a submesh. All <mesh> elements have indices and point to a 
common data block. Herer an exmaple from a virtual character:

     <group id="male">
         <group shader="#m001_body">
             <mesh>
                 <data src="json/male/male-body-index.json"/>
                 <data src="#male-skinning"/>
             </mesh>
         </group>
         <group shader="#m001_head">
             <mesh>
                 <data src="json/male/male-head-index.json"/>
                 <data src="#male-skinning"/>
             </mesh>
         </group>
     </group>

In the data block #male-skinning the animated common mesh data is 
contained. The two json files contain the indices of the "submeshes".

* Mesh / Data plug-ins
As indicated, we have a plug-in system that allows to extend the 
supported mesh formats. In fact, it just extends the generic data 
format, because a <mesh> element is a specialized <data> element that 
expects a position entry and some optional entries. Here are two 
examples that extend the mesh format:
http://xml3d.github.io/xml3d-examples/examples/meshlab/meshlab.xhtml 
(MeshLab JSON format)
http://xml3d.github.io/xml3d-examples/examples/openctm/openctm.xhtml 
(Binary OpenCTM format)

These examples are for files that don't have any structure, i.e. only 
one mesh data set. One can also register formats that are structured and 
contain multiple meshes and shaders. It's a little bit more complex but 
still reasonable. If you want to do that, come back to me and I'll give 
you some pointers. Some information on the structure and plug-in system 
can be found in [1].

* Shader plug-ins
xml3d.js allows to register own GLSL shaders. One has to deliver the 
code as well as some semantics for the shader compositing. As Phillipp 
mentioned, we are working on a more sophisticated solution for surface 
shading. Until then, you can have a lokk at this exmaple how to register 
your own shaders:
http://xml3d.github.io/xml3d-examples/examples/eyelight/eyelight.xhtml

* Physics:
We had a physics module, but that's somehow outdated. However, the 
mechanism described in our paper [2][3] is still an option.

* Primitives:
As I said, we don't have predefined primitives. But one can generate 
primitives from parameters using Xflow. A very basic example is here:
http://xml3d.github.io/xml3d-examples/examples/xflowWave/xflow-wave.xhtml

Here we generate a simple plane from some tessellation parameters. 
Agian, we use a plug-in mechansim to register new Xflow operators:
http://xml3d.github.io/xml3d-examples/examples/xflowWave/myxflow.js

* XML3DRepos:
This is a collaboration with UCL (Jozef Dobos and Anthony Steed). Assets 
are stored in a NoSQL database and we use a REST interface to query the 
assets in several formats. Details can be found in the paper [4] and 
here [5]. The link to the repo is here:
http://verser2.cs.ucl.ac.uk/xml3drepo/

Please be aware that this is very experimental and the server and 
database runs on an old desktop PC at UCL. Also, not all assets are in 
the newest DB format and thus not all examples will run. In order to 
prevent any misunderstandings, please pass this link only internally.
We uploaded the Oulu city model. It'snot perfect yet, one has to play 
with the Blender COLLADA exporter options a little and see what really 
ends up being in COLLADA. But it's good enough to get a first impression:
http://verser2.cs.ucl.ac.uk/xml3drepo/oulu3dlive/?meshformat=json

* Texture compression:
We don't support this in xml3d.js yet. Wouldn't be too hard to add it. 
But one should be aware that there are also disadvantages using S3TC:
     - Need a fallback mechanism, if S3TC is not supported. S3TC is not 
an official extension of WebGL, mainly because it's not loyalty free. 
However, the support is not too bad (~90%). I expect that the support 
particular on mobile devices that come with their own TC formats (iOS: 
PVRT, Android: ETC2) is bad. Fallback would be to decompress the 
compressed texture in JS. In a RESTful environment, one could request 
only supported texture formats.
     - 4bpp is quite large compared to good old JPG and huge compared to 
JPEG2000 or WebP. Again it depends on what's the bottleneck that the 
user experience suffers from most: Delivery time, rendering time (or 
even crashes )because GPU memory limits exceed...
     - If one wants to process the texture on CPU using Xflow, it's 
necessary to decompress the image data.

However TC is an important topic and it would be great to have a generic 
support for different TC formats. Also ASTC is already in the starting 
blocks!

Best regards,
   Kristian



[1] 
https://graphics.cg.uni-saarland.de/2013/xml3djs-architecture-of-a-polyfill-implementation-of-xml3d/
[2] https://graphics.cg.uni-saarland.de/2011/sonsvriphys2011/
[3] https://dl.dropboxusercontent.com/u/2483732/papers/xml3d-physics.pdf
[4] https://graphics.cg.uni-saarland.de/2013/xml3drepo/
[5] 
http://3drepo.org/portfolio/xml3drepo-a-rest-api-for-version-controlled-3d-assets-on-the-web/









-- 
_______________________________________________________________________________

Kristian Sons
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH, DFKI
Agenten und Simulierte Realität
Campus, Geb. D 3 2, Raum 0.77
66123 Saarbrücken, Germany

Phone: +49 681 85775-3833
Phone: +49 681 302-3833
Fax:   +49 681 85775--2235
kristian.sons at dfki.de
http://www.xml3d.org

Geschäftsführung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff

Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
_______________________________________________________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20130909/cc7bd351/attachment.html>