[x3d-public] Re: Fwd: Priorities
Joseph D Williams
joedwil at earthlink.net
Thu Oct 15 16:29:52 PDT 2020
➢ How else does it find “another node” except through an attached route
Please look at Script directOutput
With directOutput true, where the script interfaces are listed, one target is another node interface instead of the name of an interface named in a route.
Joe
From: Christoph Valentin
Sent: Thursday, October 15, 2020 3:36 PM
To: Joseph D Williams; John Carlson
Cc: Andreas Plesch; Leonard Daly; X3D Graphics public mailing list
Subject: Re: [x3d-public] Fwd: Priorities
Hi John,
I am not the right person to bring this discussion forward as a whole,
but I think I can add my two cent to your concrete question [...]How else does it find “another node” except through an attached route? Explain please.[...].
You can distribute a pointer to a <Script> node via SFNode events, fields or variables.
Then take the pointer (I think it is actually a reference) and address the field:
scriptPtr.fieldname = value.
I made extensive use of this feature in my abandoned framework.
Chapter 3 of following hobby report: https://github.com/christoph-v/spark/blob/master/3rd-party-input/SrrTrains-v0.01/HobbyReports/hr006-MIDAS-best-current-practices-v4.3.pdf
kr
christoph
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 15.10.20, 23:41 schrieb John Carlson <yottzumm at gmail.com>:
How else does it find “another node” except through an attached route? Explain please.
John
On Thu, Oct 15, 2020 at 4:38 PM Joseph D Williams <joedwil at earthlink.net> wrote:
• Script node or field node was not considered first class X3DOM nodes so we couldn’t route to/from it
The x3d script node can either in/out data using routes or directly to/from another node no route using direct out.
The only difference is that directout do not initiate a cascade because no route.
Thanks,
Joe
From: John Carlson
Sent: Thursday, October 15, 2020 2:18 PM
To: Andreas Plesch
Cc: Leonard Daly; X3D Graphics public mailing list
Subject: Re: [x3d-public] Fwd: Priorities
I believe it was Leonard’s conclusion that the script tag could not be overridden, but now it a appears that there’s a way to implement new scripting languages (brython) inside the script node. Can we modify/add X3D script fields and routes to X3DOM to provide events for a new scripting language?
Leonard, can you weigh in on adding a new scripting language to the script node?
Thanks!
John
On Thu, Oct 15, 2020 at 4:06 PM John Carlson <yottzumm at gmail.com> wrote:
Yes, we are considering 2 different tags, script and X3DScript. What we’re trying to figure out is whether script tag can be overridden/extended to provide fields in X3DOM. I believe this can be done by providing a new script type (ala brython). We know X3DScript already has fields, but we need more research on events and routes.
On Thu, Oct 15, 2020 at 3:51 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
Hi John,
yes, your memory is correct. x3dom does not know about a script or
x3dscript x3d node. You would have to implement it as a new node.
-Andreas
On Thu, Oct 15, 2020 at 4:09 PM John Carlson <yottzumm at gmail.com> wrote:
>
> Yes, I’ve added the field types.
>
> Now the question for the master branch is, what JavaScript is necessary to add fields to X3DScripts, and how do we mesh Protos with X3DScripts.
>
> The question for the Script branch is whether it’s going to work with existing X3DOM architecture, in particular, what were the issues behind previous implementation efforts. I think the best way forward would be implement a new scripting language for script nodes which includes fields. We should be able to follow brython’s example.
>
> For me, the failures of previous attempts were found in the debugger. If I recall correctly, the Script node or field node was not considered first class X3DOM nodes so we couldn’t route to/from it. I need to start the debugger again.
>
> On Thu, Oct 15, 2020 at 8:30 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
>>
>> All field type constructors and methods are defined fields.js . Since x3dom is operating together with other scripts on the page everything needs to be namespaced. Instead of
>>
>> new MFInt32()
>>
>> there is a
>>
>> new x3dom.fields.MFInt32()
>>
>> I think John added appropriate helpers which should work in an encapsulated function scope under which all X3Dscripts execute.
>>
>>
>>
>> ---on the phone---
>>
>> On Thu, Oct 15, 2020, 2:45 AM Don Brutzman <brutzman at nps.edu> wrote:
>>>
>>> Color me very surprised if X3DOM doesn't have field types already.
>>>
>>> On 10/14/2020 8:52 PM, John Carlson wrote:
>>> >
>>> > I've added the following test to x3dom (coderextreme's master branch). There are some pretty basic things such that it doesn't work, below--MFInt32 not defined. Do I need to define all field Types? Can do, I've done it before! I probably need to do it in the same scope as initialize?
>>> >
>>> > I will pursue adding field types for now. Wish me luck!
>>> >
>>> > Thanks.
>>> >
>>> > x3dom-full.debug.js:45007 Adding fields
>>> > x3dom.registerNodeType.defineClass.nodeChanged @ x3dom-full.debug.js:45007
>>> > x3dom-full.debug.js:45034 Number of fields 6
>>> > VM46:31 Uncaught ReferenceError: MFInt32 is not defined
>>> > at eventsProcessed (eval at nodeChanged (x3dom-full.debug.js:45126), <anonymous>:31:16)
>>> > at initialize (eval at nodeChanged (x3dom-full.debug.js:45126), <anonymous>:24:2)
>>> > at eval (eval at nodeChanged (x3dom-full.debug.js:45126), <anonymous>:236:41)
>>> > at x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged (x3dom-full.debug.js:45139)
>>> > at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:11796)
>>> > at x3dom.registerNodeType.defineClass.nodeChanged.nodeChanged (x3dom-full.debug.js:33648)
>>> > at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:11796)
>>> > at x3dom.NodeNameSpace.<anonymous> (x3dom-full.debug.js:11789)
>>> > at NodeList.forEach (<anonymous>)
>>> > at x3dom.NodeNameSpace.setupTree (x3dom-full.debug.js:11787)
>>> > x3dom-full.debug.js:45007 Adding fields
>>> > x3dom.registerNodeType.defineClass.nodeChanged @ x3dom-full.debug.js:45007
>>> > x3dom-full.debug.js:45034 Number of fields 5
>>> > x3dom-full.debug.js:45007 Adding fields
>>> > x3dom.registerNodeType.defineClass.nodeChanged @ x3dom-full.debug.js:45007
>>> > x3dom-full.debug.js:45034 Number of fields 5
>>> > x3dom-full.debug.js:45007 Adding fields
>>> > x3dom.registerNodeType.defineClass.nodeChanged @ x3dom-full.debug.js:45007
>>> >
>>> > create mode 100644 test/functional/Gears/Rotor.x3d
>>> > create mode 100644 test/functional/Gears/gears.x3d
>>> > create mode 100644 test/functional/Gears/index.html
>>> >
>>> > http://localhost:8000/test/functional/Gears/
>>> >
>>> > Thanks,
>>> >
>>> > John
>>> >
>>> > ---------- Forwarded message ---------
>>> > From: *John Carlson* <yottzumm at gmail.com <mailto:yottzumm at gmail.com>>
>>> > Date: Wed, Oct 14, 2020 at 9:54 PM
>>> > Subject: Re: [x3d-public] Priorities
>>> > To: Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>>
>>> > Cc: X3D Graphics public mailing list <x3d-public at web3d.org <mailto:x3d-public at web3d.org>>
>>> >
>>> >
>>> > I will be pursuing getting X3DScript working entirely within x3dom this evening.
>>> >
>>> > John
>>> >
>>> > On Wed, Oct 14, 2020 at 9:44 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>> >
>>> > X3DJSONLD only has limited functionality for X3DScript. I stripped it because X_ITE did not have support, so none of my X3DScripts were working. I hope we can get X3DScript added to XMLSchema, X3DUOM etc
>>> >
>>> > Thanks, Don
>>> >
>>> > John
>>> >
>>> > On Wed, Oct 14, 2020 at 9:33 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>> >
>>> > If I recall correctly, full support for SAI will require a Browser implementation. I suggest someone scope out the work for that, if any. That is, much of the functionality may be there. It’s important to distinguish X_ITE’s Browser from X3DOM’s in any case.
>>> >
>>> > John
>>> >
>>> > On Wed, Oct 14, 2020 at 9:22 PM John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>> wrote:
>>> >
>>> > Andreas, can you share any info about why field routing may not be working for X3DScripts in X3DOM? See coderextreme repository.
>>> >
>>> > When I get a chance, I will peek at proto declare/interface fields, but my understanding is those go away!
>>> >
>>> > Note that I’m not currently working on SAI for X3DOM, but I do have some preliminary steps for declaring field types.
>>> >
>>> > John
>>> >
>>> > On Wed, Oct 14, 2020 at 6:45 PM Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>> wrote:
>>> >
>>> > On 10/13/2020 8:26 PM, John Carlson wrote:
>>> > >
>>> > > Here’s may be possible: X3DScript node for X3DOM and X_ITE. PROTOs with scripts
>>> >
>>> > Script node support is is always topmost deficient. X3DOM without scripts is not compliant X3D or VRML.
>>> >
>>> > Prototypes are tied for importance, as in Really Really Important for X extensibility.
>>> >
>>> > Please continue sharing information with Andreas so that this might all land and work. Thanks John.
>>> >
>>> > 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
>>> > X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
>>> >
>>>
>>> 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
--
Andreas Plesch
Waltham, MA 02453
_______________________________________________ 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/20201015/c0187b81/attachment-0001.html>
More information about the x3d-public
mailing list