[x3d-public] Purpose of X3D > positioning component

Leonard Daly Leonard.Daly at realism.com
Thu Oct 13 20:28:04 PDT 2016


Doug,
> 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.
> ...

It does work on systems that don't have a handheld trigger (e.g., 
cardboard). It is fixed to the center of the screen. When you stare at 
something positioned at screen center, it triggers a "touch" event. 
After I had done the design, I get to play with a Vive with 2 hand 
controllers. That's like putting two mouses on a display. Not sure how 
to handle something like that yet. I know it's multi-touch, but I 
haven't figured out how to define a node where that could work on a Vive 
and cardboard.


Leonard Daly





>   
> ________________________________________
> 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
>
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20161013/8b09b597/attachment-0001.html>


More information about the x3d-public mailing list