[x3d-public] Purpose of X3D > positioning component

doug sanden highaspirations at hotmail.com
Thu Oct 13 19:57:02 PDT 2016


Sounds interesting Leonard - i gather thats so you dont need a handheld trigger? That could be very handy. I'm thinking a toolkit/component with things like that, that can be flexibly arranged by experimentors for different hardware and navigation/positioning scenarios. 
...
 
________________________________________
From: x3d-public [x3d-public-bounces at web3d.org] on behalf of Leonard Daly [Leonard.Daly at realism.com]
Sent: October 13, 2016 8:09 PM
To: x3d-public at web3d.org
Subject: Re: [x3d-public] Purpose of X3D > positioning component

Interaction





OK, what forms of interaction? We have basic pointer sensing and
interactions OK,.
Are there clues in MARS and related VR? Have a look at some of the
presentations from last SC24 that Myeong put up at googledocs.



How about Kalman Filtering on tilt/orientation and inertial sensors, and least squares phototriangulation, combined with the AR augmented reality proposed component, for a versatile headset/handset navigation/positiong component?

Doug.

There is a lot of work that needs to be done for pointer-equivalent, gaze, center-of-view, motion (walking, flying, or other) when using an HMD. What is done for a cardboard experience will be different for an HMD with paddles (Vive) or game controller (Rift) or other interface devices (e.g., Leap, etc.).

I have a rudimentary sensor for handling the look equivalent of TouchSensor. It is in the V4 additions to X3DOM and is available on Github. That sensor just begins the process of defining implementations for that level of user interaction. I suspect that the first pass at V4 will not define everything that is needed, nor will it define everything correctly; however, we need to start someplace.

Leonard Daly










________________________________________
From: x3d-public [x3d-public-bounces at web3d.org<mailto:x3d-public-bounces at web3d.org>] on behalf of Joe D Williams [joedwil at earthlink.net<mailto:joedwil at earthlink.net>]
Sent: October 12, 2016 2:07 PM
To: x3d-public at web3d.org<mailto:x3d-public at web3d.org>; Leonard Daly
Subject: Re: [x3d-public] Purpose of X3D

< > X3D has not kept up with current practices in modeling, animation,
rendering, or interaction.

So, finally an opportunity to actually make a list of features and
benifits missing from X3D.

Modeling

X3D is missing an automated method for defining deformable skin
animation bindings between skeleton and skin.
Most character model authoring systems will produce a fairly good set
of data using some author interaction and basic algorithms to
determine skin vertex assignments and weight for each HAnim Joint. X3D
can directly use binding data if exported from most any tool, but
otherwise the X3D author has to figure out these monumental details
using just the keyboard and an intense familitity with the skin mesh
vertex order of appearance in the user code, and each joint of the
skeleton.

This automation might be compared with the automatic texture
coordinates generated for the IFS, except much more complicated. But
if there was simple way to define basic bindings then the X3D author
could have a starting point for refinements.

Finally, we need some basic rules and recommendations for converting a
typical skeleton or skelton-skin rig from a typical design tool vendor
to our dearly beloved 'standard' X3D HAnim character. This is
necessary in order to reliably import animations developed in a
typical mocap setup into X3D HAnim.

Thinking of mocap, usually the skeleton may have a different number of
Joints than HAnim, and the names are different. Usually this is OK
because the HAnim playback skeleton will have a higher level of
articulation than the capture skeleton. It is usually fairly easy to
determine coorespondence between the capture and playback skeletons
and thus transport the animations, but we need some documentation and
examples showing a process

Animation

I have confidence that we have most all features needed for basic
realtime animations: timers, interpolators, easein-easout, and routes.
DIfferent methods of interpolation?
DIfferent models for producing motion?
 rigid body physics for HAnim
Different variable types for animation data?
 That is it - a big hole: X3D doesn't do quats in the user code.

Rendering

Significant interest in rendering at fixed frame intervals to video or
film (not realtime).
X3D does this fine and it is easy if you know a couple of details
about X3D, but there are no visible application handles for defining
how to make a fixed frame per second video or film from realtime
animations.

First there may be a need to import mocap-style fixed interval
keyframe data of several forms (euler, axis-angle, quaternions),
convert the data to X3D axis-angle interpolators and playback in real
time with interpolation. This is good because with tuning these
animations can be used with any 'standard' HAnim character.

Next there may be a need to import mocap-style fixed interval keyframe
data of several forms and playback using the exact same key times as
data was acquired, thus using only the actual keyvalue data with no
interpolation. This would be ok for a basic X3D video maker

Interaction

OK, what forms of interaction? We have basic pointer sensing and
interactions OK,.
Are there clues in MARS and related VR? Have a look at some of the
presentations from last SC24 that Myeong put up at googledocs.

Thanks Again Leonard for thinking about this stuff and Best Regards,
Joe




.
----- Original Message -----
From: "Leonard Daly" <Leonard.Daly at realism.com><mailto:Leonard.Daly at realism.com>
To: <x3d-public at web3d.org><mailto:x3d-public at web3d.org>
Sent: Wednesday, October 12, 2016 9:20 AM
Subject: Re: [x3d-public] Purpose of X3D




There were far more responses to this message than I thought would
happen. It has taken me a while to even make a first-pass read
through.
I want to thank people for being interested. I have started to work
on
much more detailed description of where I think X3D should go (or at
least consider). I will be posting those over the next month.

Generally, I see a strong interest in declarative 3D with a
programmatic
API. All regular, normal things should be able to be done
declaratively,
with programmatic means restricted to special cases.

Leonard Daly






I have been struggling with this topic for several months -- what
is
the purpose of X3D in the electronic ecosystem of the 21st century.
The Consortium says that "X3D is a royalty-free open standards file
format and run-time architecture to represent and communicate 3D
scenes and objects using XML" [http://www.web3d.org/x3d/what-x3d].
As
an ISO standard, X3D needs to have a long shelf-life, contain 3D
models, animation, and interactivity; and communicate this within
and
between systems using XML. To do this effectively, it needs to stay
current with industry practices while maintaining an ability to
communicate information from the past.

There is no question about X3D's handling of old data. To my
knowledge
there is no other 3D system that can display models, animation, and
interaction from 15+ years ago. In the Internet age where half-life
appears to be around 18 months, that is a remarkable achievement.

X3D has not kept up with current practices in modeling, animation,
rendering, or interaction. Work on the most recent update to X3D
(V3.3
- 2013) started back in 2009 and the document was mostly completed
in
2010. The most advanced feature is 3D volume rendering. Work on
particle systems and physics is several years before that. The
standard for animation of any model is with bones and rigs -
whether
that model is a character, a tree, or a machine. All current
renders
use shaders (code that runs on a graphics card) to create highly
realistic (or fantastic) surface appearance. Work on upgrading
interaction to support mobile devices (including multi-touch),
head-mounted-displays including game controllers, paddles, LEAP
interfaces, and other specialized devices is just beginning.

So back to my question -- what is X3D for? In 20 years time will
the
only content for X3D be 35 years old? Current content not created
explicitly for X3D won't work because X3D does not support much
more
than static modeling.

I have collected several choices. These are described below in more
or
less least to most complex (aka work). There are a lot of other
options, more towards bottom of the list. If you have other
contributions, please feel free to state so along with what you
think
it would take to get there from X3D V3.3.

 1) X3D is for static models only (no texture). This is a very good
match. There are just a few things that X3D doesn't handle and most
of
those are having to deal with interchange with other formats.
 2) X3D is for static models + appearance. X3D needs to expand to
make
full use of appearance shaders of all sorts.
 3) X3D is for models including animation. X3D needs to expand to
include at least the current practice of skeletal structure plus
rigging (attaching surface weights to various joints). This is not
H-Anim, but broader as it includes models that are not even at all
human, human-like, animals, or even "living".
 4) X3D is for runtime display. X3D needs to include all major 3D
formats. It needs to run AND use interface mechanisms of all major
platform types, including phones/tablets, HMDs, desktops, etc. It
needs to run in a browser: it needs to run as an app.
 5) X3D is everything. Well, think about that for a moment. That
means
all of the above need to be done. It also needs to be widely
adopted,
and this needs to be completed in the next 12-18 months. It would
probably take a team of 20-50 people working on a specification,
implementations, conversion, integration applications, marketing,
etc.
to accomplish this. Advocates for this choice need to have a
reality
check.

Given that we have maybe 7 part time people (right now) where does
X3D go?

--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/


_______________________________________________
x3d-public mailing list
x3d-public at web3d.org<mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org




--
*Leonard Daly*
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/





--------------------------------------------------------------------------------




_______________________________________________
x3d-public mailing list
x3d-public at web3d.org<mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org





_______________________________________________
x3d-public mailing list
x3d-public at web3d.org<mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org
_______________________________________________
x3d-public mailing list
x3d-public at web3d.org<mailto:x3d-public at web3d.org>
http://web3d.org/mailman/listinfo/x3d-public_web3d.org





--
Leonard Daly
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - Creating the Future



More information about the x3d-public mailing list