[x3d-public] Purpose of X3D

Thu Oct 13 07:10:34 PDT 2016

> < > 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> on behalf of Joe D Williams <joedwil at earthlink.net>
Sent: October 12, 2016 2:07 PM
To: 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>
To: <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
>> 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
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>

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