[x3d-public] [x3dom-developers] Prototype
Eric Maranne
eric at geovrml.com
Tue Feb 17 09:46:17 PST 2015
Hi Alan, long time no see :)
two more cents ...
cross plugin is almost impossible. It's even very difficult with
different single plugin updates ... ( ! ) , and this, I guess because no
browser has gained enough momentum to impose its own views on
implementation efficiency of protos. From a user POV, it's well defined.
>From an implementor POV, efficiency, memory management, even
compatibility with other browsers approaches (!) and underspec are as
many landmines for interoperability.
Look, even after more than a decade, rotation.multiply is leading to
opposite composition in some VRML browsers ! this is not a *big* deal
in development. It took more than a decade to leverage cross browser
extrusion behaving ... scripting engines still are not compatible (tried
this. operator in other plugin than cortona) ... it took an x3D
conformance database testing to get things going right in X3D, and it
took me years of work to port from Cortona to Contact in the last
decade. Not been using XJ3D, for my apps are stand alone, mostly web
disconnected, and porting from one plugin to the other is too much a
pain in the ... .
Interoperability is resolved nowadays by choosing a plugin, and a
container, that's why EVE is a stand alone app, and has been running
like a Swiss cuckoo clock since 1999, version after version.
So I don't think cross browser interoperability is an excuse. When in
current implementations rotations are handled differently, scripting
engines capabilities (and syntax expectations !!!) are different, protos
can't be interoperable... and it's not because of dev. difficulties.
Clearly, browsers ought now to be used in dedicated apps (like EVE for
us), while X3DOM or pure webgl or EMScripten compilations would be used
for Internet delivery/sharing.
AFAIC, in my business, today, the problem is on the table, awaiting a
decision. Infering stand alone EVE app would disappear in the end, cause
no small business may support several competing techs for long. We
already support OGRE, Contact and Unreal for different needs, but we
need convergence. Are we the only end-users on the edge of change ? any
echoes on the list ?
Hopefully, concerning Protos, since most of the underlying
implementation is shared (webGL), and if most of the middle layers
implementation is shared (X3DOM), then surely many VRML/X3D/proprietary
plugins interop landmines are gone .... RIP.
My feeling is the new 'VR plugin' is now as low as webgl ... and the
question is ... do we want to build atop, using X3D, or shifting
authoring and usability to production environment UNREAL or Unity or
else, delivering thru Emscripten.. .
Thanks Fraunhofer team for the good work, thanks Don for your obstinacy.
Eric.
eric.maranne at vr-crisis.com
Le 17/02/2015 17:49, Alan Hudson a écrit :
>
>
> On Mon, Feb 16, 2015 at 11:19 AM, Don Brutzman <brutzman at nps.edu
> <mailto:brutzman at nps.edu>> wrote:
>
> First, congratulations X3DOM developers. Getting to embedded
> Script nodes inside of Prototype declarations is about the most
> sophisticated thing that there is in X3D. Indeed it is a major
> language feature for Extensibility (the X in X3D). So if we get
> that working in X3DOM, everything else is easier. 8)
>
> Attached please find a recently drawn diagram that sheds some
> light on when values of embedded Script fields get initialized or
> overridden, and also when they don't. Perhaps some folks will find
> it helpful. Comments and improvements welcome, I'll be cleaning
> it up and adding an electronic version to the other prototype
> resources.
>
> I'm pretty sure that Xj3D satisfactorily supports everything
> (ProtoInstance fieldValue ExternProtoDeclare ProtoDeclare Script
> field IS connect). We recently improved some of the console
> diagnostics there, which has helped in scene debugging. If
> problems are still encountered, then they are typically elsewhere
> in the scene graph. Running open-source Xj3D within Netbeans in
> debug mode lets us drill down to any line of code necessary.
>
> Xj3D never got all the interactions working completely right. We made
> an heroic effort but getting cross browser PROTO's working is not
> easy. I'd suggest this has proven not possible at least given all the
> data points we've seen on interop issues.
>
>
> So implementing this proven, standard, working capability would
> seem to be worthwhile. Certainly seems easier than creating a new
> nonstandard extension mechanism that doesn't support X3D content.
>
> The only thing proven is that after a decade of trying a bunch of
> dedicated people cannot make them work.
>
>
>
>
>
> On 2/16/2015 9:13 AM, Don Brutzman wrote:
>
> It would be good to discuss strategies for eventually
> implementing X3D prototypes.
>
> Lots of X3D players have implemented prototypes, so they are a
> well-proven technology.
>
> Other opportunities for implementation in X3DOM may emerge.
> For example, if there is a design pattern for mapping an X3D
> ProtoDeclare into X3DOM source code, then we could write an
> XSLT stylesheet to provide such a conversion on demand.
>
> Sounds less efficient than simply implementing prototypes in
> X3DOM, but it is a path.
>
> Incidentally, in case anyone had a mistaken impression, there
> are no "native XML tags" for prototypes in the .x3d syntax.
> Example invocation:
>
> <ProtoInstance name='TimeDelaySensor'
> DEF='TimeDelaySensorExample'>
> <fieldValue name='description' value='double click to
> initiate time-delayed event'/>
> <fieldValue name='delayInterval' value='1'/>
> </ProtoInstance>
>
> Similar syntax using the @name attribute is provided for
> ProtoDeclare and ExternProtoDeclare. References:
>
> http://www.web3d.org/x3d/content/X3dTooltips.html#ProtoInstance
> http://www.web3d.org/x3d/content/X3dTooltips.html#ProtoDeclare
> http://www.web3d.org/x3d/content/X3dTooltips.html#ExternProtoDeclare
>
> http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter14-Prototypes
> http://x3dgraphics.com/slidesets/X3dForWebAuthors/Chapter14-Prototypes.pdf
> https://www.movesinstitute.org/Video/Courses/X3dForWebAuthors/X3dForWebAuthorsVideo.html#14
>
> all the best, Don
>
>
>
> all the best, Don
> --
> Don Brutzman Naval Postgraduate School, Code USW/Br
> brutzman at nps.edu <mailto:brutzman at nps.edu>
> Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA
> +1.831.656.2149 <tel:%2B1.831.656.2149>
> X3D graphics, virtual worlds, navy robotics
> http://faculty.nps.edu/brutzman
>
> _______________________________________________
> 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
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150217/fe4817ff/attachment-0001.html>
More information about the x3d-public
mailing list