[X3D-Public] HTML5 X3D meeting minutes - March 9 2010

[John A. Stewart]

What: 		Web3D HTML5 meeting March 09, 2010
present: 		John Stewart, Johannes Behr, Joe Williams, Don Brutzman,  
Anita Havelle, Leonard Daly, Philipp Slusallek.
absent: 		

Web page: 	http://www.web3d.org/x3d/wiki/index.php/X3D_and_HTML5

Topics:


1) Don - Will theHTML5 group be presenting tutorials at the Web3D  
Symposium? General consensus - yes.

2) Dr. Philipp Slusallek was requested to join and outline his group's  
XML3D proposal.

Philipp;

- Discussions started with Johannes; project came out of a meeting  
with him.

- Did not agree with Johannes about whether to put it directly into  
browser.

- re-think approach as to how to put 3d graphics into browser so that  
people would not have to learn new stuff.

- since presentation at SIGGRAPH 2009 - defined spec; ways to define  
non-rendered organizational data; define shader to interpret arrays,  
raw data is almost always arrays. Ideally all data on gpu only whether  
raytracing or rasterization..

- IndexedFaceSet is a complex structure - need data in main memory and  
gpu. - want only on gpu.

- scripting - use existing X3D structure mainly.

- x3d element - def section, group nodes, apply transformations to  
group nodes, etc. modify transformations, etc..

- use css to do transformations.

- meshes consist of arrays, gets semantics and name; this then is  
bound to shader variable.

- implementation - version of spec; code into firefox and webkit;  
interfaces thus are correct and consistent, have to do browser  
independent implementations because internal details differ between  
browsers.

- have javascript version of XML3D scenegraph and use WebGL.


- shader - anySL - portable shading language. no shader will work both  
in rasterizer or ray tracer.

- CeBIT - wikipedia page about venice; showed data on real-time  
raytracer view of Venice embedded into firefox.

- There is no api; just DOM. use standard API of DOM to manipulate  
attributes.

- HTML Browsers are not about api's while the web is a data-driven api  
via DOM.

- We are finalizing the details on spec and will put it on line as  
quickly as possible. Firefox modified browser possibly.

Don:- would like a list of shortfalls in x3d; would like to hear more  
or knowledge that we can share to help each effort.

Philipp: One of the basic things is to really pin things down to the  
most basic things; eg, do not support indexed face set .

Johannes; you have a variation of x3d? meshes, support for animated  
CSS for transformation.

Johannes: declarative material properties required - solely shaders  
will not do.

Don: how do you reconcile DOM access with pushing everything down to  
the GPU-how do you communicate back and forth?

Philipp: - firefox version - DOM objects are thin layers over scene- 
graph library; this manages all 3d data; DOM is just an API.

Don: - what about picking, etc?

Philipp: - mouse over to mesh.

JohnS - If you push all data to the GPU, is collision to objects  
possible?

Philipp - no, do not currently implement collision.

Philipp - rasterizers have issues with certain 3d graphics problems;  
if you want to put 3d graphics into firefox; use ray tracing; shadows,  
refraction, etc.

  - it HAS to work; if it does not, it will be forgotten because users  
will wander off and use another system.

- submitted paper to SIGGRAPH 2010 about this work.

Don - you were going to submit an X3D browser - will you finish  
releasing it?

Philipp - no - moved on from that.

Don - do we need another profile for mobile, html5, etc? This question  
keeps coming up; do we need an HTML profile?

Philipp - another design choice - mesh is a container that has a  
shader associated with it; within the mesh there is no semantics;  
takes a generic array binds to a name;  those arrays are actually the  
output of shaders again; designed it so that they can replace any of  
those arrays by outputs of shaders.

Johannes - x3d - no way of putting the output of shaders back into the  
scenegraph (? did I get this comment right? )

Philipp- anySL - an intermediate shader language.

Joe - Rigid body physics - would it fit into your idea?

Philipp - beyond what we know right now. We have the most flexible  
approach; but again we have not figured out all of the details, not  
clear what you can and can not do.

Philipp - back to anySL - SSE code or SIMD code automatically from  
anySL; you might not want to do this for a browser.

what we are doing, please take this as 2 things ; 1) research  
projects, not ready for browser; XML3D is one thing that we understand  
well enough.

Philipp - would like one preferred way of specifying 3D scenes. (after  
all there is only 1 HTML...) X3D has had good success; but at this  
point in time there is a unique opportunity to remove some of the  
backwards compatibility and get a good hit at doing 3d on the web.

Don - what is a good next step?

Philipp - Web3D Sympoisum is a good place, but is a couple of months  
down the road.

all; general comment, once spec is released, we can make up lists as  
to what we agree with and what needs to be discussed.


-----------------------------------------------------------
John A. Stewart
Team Leader: Networked Virtual and Augmented Reality
alex.stewart at crc.ca

Network Systems and Technologies -
         Systemes et technologies des reseaux
Communications Research Centre Canada  |
          Centre de recherches sur les communications Canada

3701 Carling Ave.  |  3701, avenue Carling
PO Box 11490, Station H  |  CP 11490, succursale H
          Ottawa ON K2H 8S2   |  Ottawa (Ontario) K2H 8S2

http://www.crc.ca