[x3d-public] Invited guest discussion in December

Roy Walmsley roy.walmsley at ntlworld.com
Tue Jan 10 08:51:27 PST 2017

Dear all,


During the month of December the X3D working group invited two sets of
guests for discussions. Since these are of general interest, it has been
agreed that the minutes of those discussions, with permission from all
attendees, should be shared on this public list.


The first discussion took place on 7th December 2016, with Professor Philipp
Slusallek and Stefan Lemme of Computergraphics Lab, Saarland University, who
are working on XML3D, and a possible extension to X3D.


The second discussion took place on 14th December 2016 with Dr. Frédéric
Vogt of the European Southern Observatory in Chile. He is working on using
X3D to 3D print and publish data visualizations from astrophysics research.



A. Discussion Topic from 7th December


              XML3D and X3D Version 4 with Professor Philipp Slusallek and
Stefan Lemme (Web3D participants Don Brutzman, Joe Williams, Anita Havele,
Roy Walmsley)


Follow up discussion to that originally held at Siggraph in August. Summary
mail submitted by Philipp Slusallek to the public mailing list on August
15th 2016


Reference: Lemme, Stefan, Sutter, Jan, Schlinkmann, Christian and Slusallek,
Philipp. The Basic Building Blocks of Declarative 3D on the Web. Proceedings
of the 21st International Conference on Web3D Technology of Web3D '16 , page
17-25. http://dx.doi.org/10.1145/2945292.2945303,


Philipp: We have been continuing the development of XML3D. There have been
no fundamental changes. More work has been done on the compiler side. XML3D
is a stable implementation, the  current version being 5.2.1.


Don: Philipp’s Web3D paper very helpful.


Philipp: We have some slides which could be made available soon.


Don: This is an X3D V4.0 architectural opportunity. We have to show
backwards compatibility rather than strict alignment. We are working on
correlating the event model between the two implementations X3DOM and
Cobweb. The same example was illustrated in the two implementations a week


Philipp: We are coming from a slightly different direction. We want a
declarative approach, integrated into DOM within HTML5. We started from the
side of HTML5, minimizing new concepts to do interactive 3D graphics in the
DOM. We have full support for programmable GPUs. This is where concepts such
as XFlow and ShadeJS come from. We show that layers can be built on top of
that. The Web3D 2016 paper showed that core library. It relies on
WebComponents. We can layer X3D on top of the core engine. We can do many
X3D nodes, and probably could do most.


Don: We are focused on achieving a strong, high performance engine,
integrated into the DOM / HTML5. 


Philipp: Key difference is where X3D has a large number of nodes spread over
specific domains, we tried to produce a minimal set of basic building


Don: Maybe there is an area of overlap and synergy that could be built upon.
The component approach is sensible. X3D has profiles, as well as Components,
and even levels within Components. Implementers do not have to do
everything, but can do small portions at a time. XML has the flexibility to
optimize deeply. X3D has to be careful not to be over prescriptive about


Philipp: With regard to modularity and components I have two answers. One is
that of breaking a larger system down into smaller components. Second is
using WebComponents, building a layered approach. Demonstrations were shown
at Web3D 2016, one of which was a character. It was not fully H-Anim, but
one that could be built so. Key part of XML3D is the generic data
representation, and the ability to apply computations to collections of
fields. Data nodes capture sets of data (sets of buffers, in GPU terms).
This concept does not exist on the X3D side, so more difficult to design


Don: Referencing Figure 2 In the Web3D 2016 paper, particularly data
elements, the Coordinate node has a set of vertices that can be shared.
IndexedFaceSet could use Coordinate node. If I want to create
IndexedLineSet, I would need to duplicate the Coordinate node. This shows
that X3D does not have the representational capability of XML3D. 


Philipp: In XML3D, data does not have semantic notation attached. The data
is simply a float3 array. Semantics are only provided when data is attached
to a mesh element.


Don: We do have strong typing for data in nodes. Coordinate has MFVec3f
field, which is common to other nodes, such as Normal.


Philipp: We take a functional approach, advocating use of XML3D ideas into
V4 of X3D (with admitted bias). What is the best way to include this? Use
of XML3D has been shown to work. Other way might be to design new general
nodes within X3D, and build other nodes from them.


Don: Suggest we need to look at examples.


Philipp: Examples are a good idea.  See our assets paper at Web3D 2014:
Configurable Instances of 3D Models for Declarative 3D in the Web. (DOI:
10.1145/2628588.2628594 <http://dx.doi.org/10.1145/2628588.2628594> ,
s-for-declarative-3d-in-the-web/> )


Joe: Congratulations on good work. Higlighted Collada and glTF, H-Anim
models, skin and bones animation, Displacer style, transport animation.
Asked about Sensors?


Philipp: Two answers. One is many ways to specify mesh, skinning, morphing,
animation etc. Not just the one way of doing things. XML3D took the approach
to not codify one particular way, but provide building blocks to allow
different techniques to be used without requiring data conversion. Have
XFlow mechanism for defining the information. Then have operators to provide
mapping. Flight deck (???) for Web3D paper on GitHub has example of
character animation. (Need LINK). No programming needed. 


Joe: Looking for other examples of implementations.


Philipp: Several papers have been published covering improved techniques for


Philipp: About glTF and Collada. Kristian provided a converter. XML3D has a
format converter. Able to register new formats.


Don: SRC from Fraunhofer, now pretty well aligned with glTF. 


Philipp: Have “BLAST” Paper: Blast: A Binary Large Structured Transmission
Format for the Web  (DOI: 10.1145/2628588.2628599
<http://dx.doi.org/10.1145/2628588.2628599> ,
ansmission-format-for-the-web/> ). Blast designed to be useful for different
types of data, not just geometry data. Not wanting to impose anything, just
provide the ability. GPU data might be of various types. Some standard
compression types, simply reference them. Otherwise can reference a URI to
decompress (“code on demand”).


Philipp: Haven’t implemented SRC. 


Don: Have a JSON encoding. Also progress on EXI compression – W3C are
changing the name to ‘Efficient Extensible Interchange’ to reflect
application not just to XML, but also to JSON. 


Roy: Re the implementation example referred to earlier, I would like to try
in XML3D. Is the XML3D implementation available to test this?


Philipp: The current public implementation does not have the capabilities of
the web components. The new version with the Web components is not yet
available. It is still being a work in progress, not ready for public
release. However, would be willing to share it on a bilateral basis.
Concerned about giving a poor impression, as it has rough edges. It would,
though, be an Interesting exercise to look at more complex X3D nodes to see
how they might map.


Don: We have been working on JSON, which has a fully decorated schema. We
also have an auto generated X3D Object Model, and are using it to auto
generate a JAVA codebase. Might be able to also auto generate WebComponents
structure for X3D nodes.


Philipp: Called the approach Declarative 3D. The technology stack is
highlighted in Figure 5 of the Web3D 2016 paper. All use the same
infrastructure. Performance improvements for all simply by improving core.


Anita: Two or three years ago, the W3C Declarative 3D group was formed,
although it is no longer active. It included correlating XML3D and X3DOM.
Have you been working with Fraunhofer?


Philipp: Not really working with them, as they stopped working on the
declarative level. We didn’t have a project previously. Having started work
with the introduction of WebComponents, we have the right technology to
become standard. Happy to resurrect the Declarative 3D group, if there is


Anita: The Declarative WebVR group is starting. There is overlap with the
Declarative 3D group.


Philipp: WebVR not really declarative, although Tony Parisi presented some
material at Siggraph. Declarative not well defined in the VR context.


Don: I like the idea of Declarative 3D group restarting.


Philipp: Have an implementation of WebVR within XML3D in 5.2 version. Expect
WebVR to be one of those Level 5 libraries. We are interested in X3DOM
approach to WebVR, and have a student who could do this. There is a lot of
Interest in standardizing WebVR, and also Declarative 3D. Students are
available. Prefer to start in the trenches with examples and coding.
Standards follow.




B. Discussion Topic from 14th December


              X3D and 3D Content in Scholarly Journals with Dr. Frédéric
Vogt (Web3D participants Vince Marchetti, Leonard Daly, Don Brutzman, Joe
Williams, Anita Havele, Roy Walmsley)


Frédéric: Connect scientific datasets to 3D graphics.


Vince: Priority with Web3D is to encourage adoption of X3D. What obstacles
did you encounter? What can we do better?


Frédéric: Stumbled on X3D and managed to get things moving fairly rapidly.
Datasets in astrophysics are very custom, with exotic file formats. Data is
multidimensional. How to go from custom formats to X3D. Python module –
MAYAVI (http://mayavi.sourceforge.net/). How can scientists bridge gap? VTK
exporter, has issues. Can create models. Recognize publication is important,
even for career development. Have to deal with journal editors. One guy vs
the big publishers. Able to meet editors, and get promotional agreement.
Like the idea of online figures. This is just one set of journals within
astrophysics. Difficult to standardize across all types of publications.
Format itself an  issue. Ability to include axes, grids, and labels is


Vince: Axis discussion. Use MAYAVI python library.


Frédéric: MAYAVI python library – supports axes, etc. Export does not
support them though. 


Vince: Working with publishers, recalled an attendee at Web3D 2016 from
public library of science, whose interest was biology. What do you submit?
X3D file or web page?


Frédéric: Send publishers the web page – X3D file + X3DOM wrapper. Important
to include use of interaction buttons. These are a useful guide for the
reader. Viewpoints and layers are useful. Different, of course, in every
case. Recently discovered clip plane ability. Can make use of it to take
measurements. Readers can do this down the line.


Roy: Should X3D have a grid node?


Leonard: No – too many variations – etc. Should be the realm of an


Frédéric: Like python module, easy to use. Blender, open source, but steep
learning curve. MAYAVI can generate something with five lines of HTML code.
Interactive and 3D.


Vince: X3D a text based format – can cut and paste readily. 


Frédéric: Drew axes in MAYAVI, using lines and cylinders. X3D model is only
a small part of the scientific process. Need to visualize and understand.
Blender is generally too complicated. Need simple tools.


Don: MAYAVI – are you writing code and then exporting X3D?


Frédéric: Has python script, run script. Have 3D window, and export 3D


Don: Will ensure is included on X3D resources file. MAYAVI is related to
VTK. VTK generally responsive to suggestions and fixes. Should we be listing
workflows, capabilities, etc. for these tool builders. What’s different
about publishing with X3DOM and Cobweb as opposed to other HTML libraries?
An inhibitor is that implementations don’t always have the advantage of
extensibility. Don’t want a super node as already mentioned. Already good
visualization tools available. Prototypes not available in X3DOM. Inlines
useful with IMPORT / EXPORT events. Gotten pretty far on a prototype
expander that acts as a pre-processor to work around a lack of prototypes.


Anita: Main goal to increase adoption of X3D and outreach. Would like to
show case examples.


Frédéric: In astrophysics, especially for radio observations, have been
receiving 3D data for a long time. Have developed tools and ways of thinking
into 2D chunks for presentation. Seeing more examples is good. Need to show
how it can be done, and show the benefits of 3D presentation. Shows we can
do things differently.


Anita: Documenting workflows to improve usage. Happy to display on our
website, assuming it is open.


Frédéric: Everything is open, and available of GitHub. Have four examples
now. Some basic to illustrate process. Another with full dataset. Happy to
share and help on our site. GitHub site is:


Anita: We have a Web3D conference in June. Possibly a paper, or tutorials /


Don: Bunch of wizards, authoring assists. Could make these more obvious.
Liaise with others to make this more available, e.g. public library of


Frédéric: Agree need to interact. So far been very individual. Way forward
is to create a momentum and get a global effort, and different scientific
domains. Clip planes allow extraction of new information from the data. Good
to have a tool to assist this.


Don: 3D printing workshop at Web3D 2016. Medical workshop – with cardiac
surgeon and radiologist, illustrating a baby’s heart. Printing a 3D model
shows the pathology that otherwise would not be seen until the patient was
cut open. Part of the visualization and understanding.


Joe: Also seen the benefits in Chemistry, with molecules, etc. Is this a
potential working group study area?


Vince: 3D models are shells, or contour lines. MAYAVI are computation tools
that calculate those. Is volume rendering something that might be useful?


Frédéric: Data is essentially volumetric data. Not gone down this route yet
is because of software limitations. Also, data is complex, so simpler shells
/ contour lines can be helpful. But volume rendering would be useful too.


John: Could you export data into a template.


Frédéric: Has weird and custom file formats. Can import, but not well.
Python gives the flexibility. Format is FITS (Flexible Image Transport
System – see http://fits.gsfc.nasa.gov/). All telescopic data is in this
format. Say working with a 3D data cube. In Python it only takes a few lines
to convert it to a text file.

[ Post meeting note from John: There’s a JavaScript library in development
for reading FITS:  https://github.com/astrojs/fitsjs/ I don’t know it’s
applicability to this situation. ]


John: How do you convert the images into shells? Are shells in a different
file format to images?


Frédéric: Need a smoother, easier process. Need to convince people and
demonstrate usefulness. Then have to show how difficult it is to use it.


John: Geographic projections with d3.js. Placement of geographic data on a
web page. Thinking about multiple levels of coordinates.  Suggestion to
combine d3.js with x3dom.


Frédéric: Interesting analogy. Looking at sky, just the other way. Wide
range of needs. Volume, shells, grids, annotations. Scientists ask for


Don: Tease out constructive paths forwards. Learning curves. Not just does
it show value. Not just what do I need to do to make it work. But also, will
it break next year? Longevity.


Frédéric: Always the argument on longevity. People always have strong
opinion one way or the other. Have been doing without it for years –
entrenched view. Supervisors and fund managers have to be convinced. There
are some people that see the benefits and want to advance forward. Need to
get journals on board. Need an X3D guru to provide support. 


Anita: Consider ourselves a technology for serious 3D. Archivability,
backwards compatibility. How did you learn about X3D?


Frédéric: Learnt about X3D two years ago. How, I forget. Looking at PDFs.
Stumbled onto it by accident – took a lot less effort than PDFs. How to
promote this? To some extent has to come from the field. Scientists have to
lead by example.


Don: Home web page – real time 3D. Now talking about real time 3D
publication. Shift from text to 2D images probably had similar problems.


Frédéric: Change to 3D will happen. It is the tools and, primarily, the
journal acceptance that will lead the way. SKA Consortium
(https://www.skatelescope.org/) looking at using X3D.


Don: Could also generate models of telescope. CSIRO also park of SKA. But
already part of Web3D, but cultural heritage.


Anita: CSIRO also hosting the conference. How can X3D help? Would Frédéric
be a champion in this field?


Frédéric: Consortium should think in terms of science, in general. How to
promote in practice. If there was a contact point that would be helpful.
Three way between the author, the Consortium, the journal.


Don: Scientific X3D might be the name for this. Publication, education, are
terms that are too broad.


Frédéric: Likes the idea of Scientific X3D. How do I have my X3D model
validated? How do I publish it and have it available? Scientific X3D Working


Vince: Sounds like Frédéric’s challenges are not the science, but the
publishing. Caution, but some concern that different disciplines have
different requirements, e.g. Medicine vs Astrophysics.


Frédéric: Still have similar problems. Might have units differences. Still
asking the same general questions.


Joe: “Real Time Scientific Visualizations and Analysis on the World Wide


Don: Hope to have better practices emerge.


Roy: Is there a need for 4D? Time?


Frédéric: If time was the fourth dimension – universe is dynamic. Absolutely
clear need for this.


Joe: Helpful to focus this on astronomy and astrophysics. Historically
Frédéric would get a couple of people together, and build a workflow,
creating a focus working group. They could generate results useful for
demonstration and presentation.


Frédéric: Getting to a stable point in one field would then allow pick up on
this in other fields. This is an alternative approach.




All the best,


Roy Walmsley

X3D WG co-chair

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170110/5e21f721/attachment-0001.html>

More information about the x3d-public mailing list