[x3d-public] X3D APIS for Qt, Python, ECMAScript

Mon Mar 2 10:56:15 PST 2020

I suggest people run my unit tests and confirm that they are still working
properly, and then go into seeing if we can see modifications on the
original to object (called node I think).

On Mon, Mar 2, 2020 at 12:28 PM John Carlson <yottzumm at gmail.com> wrote:

> Here is the route code I actually wrote unit tests for.   It has a get
> proxy, but we might be able to unify proxy action and node with a different
> set/get proxy.   I recall that it didn’t appear that setters were working
> on the original JSON???  Or was it the getters that didn’t work?
>
> This should be standalone JS.
>
>
> https://github.com/coderextreme/X3DJSONLD/blob/master/src/main/node/route.js
>
>
> On Mon, Mar 2, 2020 at 12:08 PM John Carlson <yottzumm at gmail.com> wrote:
>
>> I too am interested in Godot for our RPG project, but we are targeting
>> non programmers.
>>
>> I echo your desire for a JSON scenegraph with proxies for routes.   I
>> think a small addition of a get proxy to X3DJSONLD’s route.js may get us to
>> that target.   The advantage of that is we’d be able to use paths to
>> objects in the route.
>>
>> I busted my brain over the JSON PrototypeExpander for X3D.   I suggest
>> further work on this for XML objects would be a good extension for X3DOM.
>> In other words, we can convert JSON PROTOs to XML, and then bring them
>> through a new HTML PROTO expander, and the JSON one will be deprecated.
>> Also, there needs to be a disciplined set of test cases for the proto
>> expander.   I can’t just take an adhoc set of examples, we need
>> mathematical rigor in the unit tests.   This is the first step for any work
>> on the proto expander.
>>
>> I believe the first step of making a JSON scenegraph is editing the proxy
>> code in route.js.
>>
>> route.js provides both a two level and a path oriented approach to
>> routes.   I have already suggested adding a path oriented route extension
>> to X3d, but I haven’t written up the text yet.   Suggestions on where to
>> add the text to the standard are welcome.   Also, I believe this will
>> require an MFScalar type similar to MFString.
>>
>> On Mon, Mar 2, 2020 at 10:31 AM Andreas Plesch <andreasplesch at gmail.com>
>> wrote:
>>
>>> > Date: Mon, 2 Mar 2020 06:44:44 -0800
>>> > From: Don Brutzman <brutzman at nps.edu>
>>>
>>> ...
>>>
>>> > 3. Next: also had a old+new idea to consider following recent
>>> discussion with Katie Unger of Synergy Software Design (cc:ed).  What if we
>>> used X3DUOM and autogenerated an ECMAScript SAI for X3D called X3DESAIL
>>> that patterned X3D scene graph accessors following your X3DJSONLD patterns,
>>> was primarily oriented towards Node.js, and also added utility methods
>>> facilitating use in combination with X3DOM X_ITE and Three.js.  That
>>> harmonization might be something widely useful.
>>>
>>> Let's see how utility methods of a X3DESAIL could be useful.
>>>
>>> An EcmaScript Scene Authoring Library presumably would just use a JS
>>> object which corresponds to the JSON encoding for its internal, in
>>> memory representation of a scene graph. So it would be straightforward
>>> to write back out JSON for loading into x3dom and x_ite. It would also
>>> very be useful to generate xml encoding since John indicated limited
>>> availability to maintain the json loaders John generously provided for
>>> x3dom and x_ite. This way X3DESAIL could be used as a json loader.
>>>
>>> Both x3dom and x_ite have their own in memory representations of the
>>> scene graph and its state (stacks, execution contexts, viewpoint
>>> offsets, time, events ..). For X3DESAIL to become useful in managing
>>> and accessing a running scene, it would need a fuller model of the
>>> running scene graph which seems unlikely.
>>>
>>> For three.js, it should be possible to generate a limited, more
>>> static, js code encoding which three.js can render. In effect, this
>>> would mean implementing a limited x3d browser using three.js. Did you
>>> have more specific ideas in that regard ?
>>>
>>> I became interested in how Godot (godotengine.org), a completely free,
>>> MIT licensed, multi-platform, open game engine, and X3D could mesh.
>>> Godot has in some ways a similar scene graph to x3d in that it allows
>>> for multiparenting (unlike three,js), has signals (events) and is
>>> flexible enough for protos, eg. there is little difference between
>>> native nodes and custom scripted nodes. It supports multiple scripting
>>> languages (C#, and GDScript builtin) including Ecmascript (by an
>>> extension). There is a potential for an EcmaScript SAI and a script
>>> node for a godot based X3D browser. Perhaps X3DESAIL could be useful
>>> there as well.
>>>
>>> -Andreas
>>>
>>> > TIA for your efforts, as always best wishes for your work.
>>> >
>>> > v/r Don
>>> >
>>> >
>>> > On 3/1/2020 3:02 PM, John Carlson wrote:
>>> > > I have added gui.x3d and gui.py as examples of translating Qt
>>> Designer XML (I think) to "X3D"-like python.? This is after a "roll my own"
>>> xmltopy.py.? There's still a lot of work to do, namely, we need to add some
>>> text node processing to X3dToPython.xslt.? ?We probably want to create a
>>> RpgToPython.xslt for that.
>>> > >
>>> > > I also added a build target for gui.py.
>>> > >
>>> > > Ideally, either Jeff or I will write the RpgToPython.xslt and
>>> associated?RPGuomToRpgPythonPackage.xslt.
>>> > >
>>> > > Any inputs everyone has are welcome, especially in the realm of
>>> creating a user friendly editor for RPGUOM like Qt Designer/WxFormBuilder.
>>> > >
>>> > > Code is found here on sourceforge:
>>> > >
>>> > > x3d-code/www.web3d.org/x3d/stylesheets/python <
>>> http://www.web3d.org/x3d/stylesheets/python>
>>> > >
>>> > > Thanks for all the contributions?that made this project even
>>> possible!
>>> > >
>>> > > John
>>> > >
>>> > >
>>> > >
>>> > > If someone wants to contribute XMLSchemas or X3DUOM-like unified
>>> object models which?support Qt Designer and/or RPG object model, they would
>>> be most welcome.
>>> > >
>>> > > I'll probably be working on an RPGUOM next.
>>> > >
>>> > > John
>>> >
>>> > all the best, Don
>>> > --
>>> > Don Brutzman  Naval Postgraduate School, Code USW/Br
>>> brutzman at nps.edu
>>> > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA
>>>  +1.831.656.2149
>>> > X3D graphics, virtual worlds, navy robotics
>>> http://faculty.nps.edu/brutzman
>>> >
>>> >
>>> >
>>> > ------------------------------
>>> >
>>> > Subject: Digest Footer
>>> >
>>> > _______________________________________________
>>> > x3d-public mailing list
>>> > x3d-public at web3d.org
>>> > http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>>> >
>>> >
>>> > ------------------------------
>>> >
>>> > End of x3d-public Digest, Vol 132, Issue 3
>>> > ******************************************
>>>
>>>
>>>
>>> --
>>> Andreas Plesch
>>> Waltham, MA 02453
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200302/c5483e01/attachment-0001.html>