[X3D-Public] HTML5 X3D meeting minutes - March 9 2010
John A. Stewart
alex.stewart at crc.ca
Thu Mar 11 12:16:50 PST 2010
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
More information about the X3D-Public
mailing list