[x3d-public] Purpose of X3D

doug sanden highaspirations at hotmail.com
Thu Oct 13 11:22:33 PDT 2016


OK V4.
Keep up the good work Leonard - look forward to seeing some v4 drafts.
more..
Q1 is about how us little guys, who may have ideas, can help the process by presenting them better / more onus on the idea presenter.
________________________________________
From: x3d-public <x3d-public-bounces at web3d.org> on behalf of Leonard Daly <Leonard.Daly at realism.com>
Sent: October 13, 2016 11:54 AM
To: x3d-public at web3d.org
Subject: Re: [x3d-public] Purpose of X3D

Doug,

I do not understand your questions, especially Q1.

For Q2, I think I am answering the right question:
My intent was to get interest and response from the community (on x3d-public) for what X3D V4 should do. As an international standard, X3D should never be out in front of the developer community. It needs to monitor the state of the (relevant) industries and "pick" the best features, processes, and methods being used that are available to standardize.

The desktop and mobile (especially) 3D & VR community is very hot right now. Developers, especially the more artistic types, do not want to write code to create a spinning box (as you would for three.js). They also don't want to have to learn 3-5+ means of doing the same thing, depending on their work environment. Of course, they also want to be able to import all of their existing models too.

So my purpose in asking for people here to comment in by suggesting options that they think will work for the community, the potential future community, and the developers within the Consortium. My initial listing of options (in short form) are:


1) X3D is for static models only (no texture).
2) X3D is for static models + appearance.
3) X3D is for models including animation.
4) X3D is for runtime display.
5) X3D is everything.

I know there are more options, and I don't remember (right now) anyone suggestion other options or refining any of these. I am currently working through some ideas that would define a multi-tiered approach that encompasses the first 4. I plan to have the first document released this week.


Leonard Daly





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




Q1. how more precisely/steps to 'gain consensus' and/or make it easy for others to test/judge ideas?
Q2. was Leonard's original intent/complaint about
a) nothing much new for v4, so why bother v4
b) nothing to show at siggraph - always begging for ideas and getting further behind, nothing to show
c) end user satisfaction with toolset completeness / maturity / convenience

-Doug
more..
#Q1. I suspect if broad buy-in is needed then something like:
1. idea listings for Like+ before doing real work/effort
- answer what, why, how, or (proposal-like) situation, objective, method, cost/effort, benefits
- but you might not get any feedback - just 'blank stares'  or no-repsonse
2. if Liked+ or no-repsonse, then
a) if prototypable, distribute prototypes for trying
b) else schedule a month for browser developers to try implementing it
-- might need to wait till Jan 2017 to get freewrlian effort

more..
I'm working on v3.3 nodes and components till Dec 31. Haven't done HAnim yet. I suspect cobwebians are also working on v3.3.

more..
I keep a list of IDEAS for future development. I could go through that and expose a few for Like+ ratings.
...
I also found one browser developer had a stash of interesting non-v3.3 node types, but they may be for proprietary differentiation, not broad adoption, although freewrl asked for and received permission to implement one.
So perhaps a rule of thumb: try it in your own browser with your early-adopter users, and then show to us other browser developers for late-adoption and spec inclusion.

more...
#Q2. if b) I suspect no one is expecting x3d to blaze the trail. Its more like a vacuum cleaner for ideas - sucking up good ideas from the floor of siggraph and getting them into more usuable form for people around the world to access/use conveniently.
Brilliant research => prototype => siggraph demo => published paper => web3d => prototypes => early adopters => consensus => new nodes/components => users around the world.
So the researchers need us. But is it the vacuum cleaner's fault if there's nothing for end users? Could computer graphics be 'mined out'? Or is the whole v3-- architecture/mindset/process/user-base somehow holding us back from implementing slew of recent innovations?





________________________________________
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