[x3d-public] External prototypes

Thu Mar 12 12:09:53 PDT 2015

>
>> Either way we do it we are still loading, and completing all initial IS and
>> ROUTE before completion of the parsing stage, aren't we? Or do you save IS
>> and ROUTE until parsing is complete and then implement them?
>

Roy,
Sorry I think I misunderstood. Yes, in freewrl we route the main scene as we parse. If we hit an EPD, we create a stub PD -no body, and the interface of the EPD- and send the url to the download queue. Then as we parse further down the main scene, and hit a EPI -an instance of the EPD- we instance (copy) our stub/empty PD. Then as we parse further in the main scene, if we hit a ROUTE that has an EPI as an endpoint, it's routed to that stub proto. When the scene has been parsed, we can start rendering it, and routing events. And that's where Kristian's comments apply to freewrl: events in the main scene can be firing before the body of the EPIs shows up, so those events will end at the EPI interface (and not be ISd to anything inside). Nothing bad happens -no crash- but if those events are one-time occurances they will be missed by the late-arriving/lazy EPI definition.
-Doug


> Delayed now in freewrl. The EPD (externprotodeclare) interface is made into a PD (protodeclare) immediately, using the EPD's declared fields, and an empty body. This empty PD is what gets instanced for each EPI as the rest of the scene is parsed. During EPD parsing, its URL is enqueued for downloading -same queue as other url resources.
> Then later -or never, if not found- when the EPD's url scene is finished loading/parsing as a 'library scene', the EPD gets a chance to get its #proto out of the library scene.
> When one of the empty EPIs is visited during scenegraph rendering, it checks with its EPD to see if a definition has showed up yet. If yes, it takes a moment to instance one in its own body, connect the EPI interface to the new instance in its body (I use routes), and register routes and bindables.
> more..
> Freewrl now uses binary protos, meaning a proto definition gets parsed from x3d or wrl only once. After that its in a neutral, binary format - almost the same format as the final node is in the scenegraph when its running.
> But this was a recent change for freewrl, last fall. Before, it used text protos -copying the x3d or wrl snippet that defined a proto, and pasting it into the parsing stream once for each proto instance. That had problems.
>
>
>> In Coin3D I have two classes - a Proto and a ProtoInstance. They both get
>> used for PROTO and EXTERNPROTO cases, with different flags. So I am like
>> you.
>>
>> When I parse an EXTERNPROTO I load immediately after reading the declared
>> fields. I guess that could be inefficient if an EXTERNPROTO was declared but
>> never instanced. Then I instantiate ProtoInstance copies as and when needed,
>> copying the Proto fields and connections.
>>
>> Either way we do it we are still loading, and completing all initial IS and
>> ROUTE before completion of the parsing stage, aren't we? Or do you save IS
>> and ROUTE until parsing is complete and then implement them?
>>
>> -----Original Message-----
>> From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of doug
>> sanden
>> Sent: 12 March 2015 16:19
>> To: 'X3D Graphics public mailing list'
>> Subject: Re: [x3d-public] External prototypes
>>
>>> On the other hand, the creation and setting up of the instance takes
>>> place when the file is being read in.
>>
>> Uh-oh. I did it differently in freewrl: I lazy-load the EPD, and bodify the
>> EPIs after that. freewrl used to load the EPD during scene parsing, but
>> there was an issue with that. I changed it so EPD, EPI, PD, PI, Inline all
>> share the same struct (with different flags). Now EPIs get the EPD interface
>> and empty body during parsing, and when the EPD definition shows up later, a
>> copy is instanced in the body of each EPI, and IS routing done between the
>> EPI interface and PI interface. So freewrl -with some changes- could in
>> theory send an event out the (inline) .load field after IS routing.
>>
>>
>>> That's an Interesting set of points you raise.
>>>
>>>
>>>
>>> I agree that the LoadSensor probably can't be used because the
>>> watchList field requires nodes derived from URL object. And
>>> EXTERNPROTO, although it has a URL, isn't a node.
>>>
>>> On the other hand, the creation and setting up of the instance takes
>>> place when the file is being read in. This will include things like IS
>>> and ROUTE, etc. So as the loading takes place during the file loading
>>> phase there is no need for the LoadSensor. Indeed, it wouldn't be able
>>> to send any messages until the setup phase was completed. Thus,
>>> referring to Kristian's comment, the loading phase for the file would
>>> proceed through the EXTERNPROTO declaration until it came to the
>>> prototype instance. This would then load immediately and be set up
>>> before reading the file proceeded to the next node. Consequently
>>> ROUTEs could be used immediately after the instance in the file.
>>> Obviously and dynamic routing (e.g. via Scripts) would not start until
>>> the whole scene graph loading was completed and became live. So there
>>> isn't an issue there.
>>>
>>>
>>>
>>> Inline, on the other hand, does not have to read the URL during the
>>> setup phase. The stated purpose of the load field is effectively one
>>> of input, not output (although it is inputOutput type). So setting
>>> load to FALSE prevents the Inline from loading until it is needed, as
>>> opposed to loading immediately if load is TRUE. The specification
>>> makes no mention of any output activity. So it would be necessary to
>>> use a LoadSensor if it was desired to monitor an Inline.
>>>
>>>
>>>
>>> I too have noted that you have to specify the list of fields For
>>> external prototypes in two places. However, avoiding that can't be
>>> easily avoided. The use of a subset of the fields does allow an author
>>> to only declare those fields of the EXTERNALPROTOTYPE that need to be
>>> in the top level file. However, there is no reason why all the fields
>>> should not be included, albeit that the specification says "shall be a
>>> subset". I think the specification ought to say "shall be all or a
>>> subset". Another suggestion for V3.4 I think.
>>>
>>>
>>>
>>> Roy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: x3d-public [mailto:x3d-public-bounces at web3d.org] On Behalf Of
>>> doug sanden
>>> Sent: 12 March 2015 14:15
>>> To: X3D Graphics public mailing list
>>> Subject: Re: [x3d-public] External prototypes
>>>
>>>
>>>
>>>
>>>
>>> I suspect Networking component> LoadSensor
>>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/comp
>>> onents/networking.html#LoadSensor
>>>
>>> cannot be used, because the URL is on the EP declaration, not the
>>> instance, and the declaration isn't in the scenegraph where LoadSensor
>>> can get to it. And there are extra steps after the declaration is
>>> loaded, to populate the instances and hook up the IS routes to the
>>> instance interface.
>>>
>>>
>>>
>>> Networking Component> Inline has a .load field [in,out] and I suspect
>>> it sends an event out TRUE when it's loaded.
>>>
>>> http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/comp
>>> onents/networking.html#Anchor
>>>
>>> Ideally EPIs would have that too.
>>>
>>>
>>>
>>>>
>>>
>>>> Ideally I think there should be a .loaded event or testable field on
>>> the externProtoInstance (the interface), so you can test / know when
>>> it's ready for routing.
>>>
>>>> -Doug
>>>
>>>>
>>>
>>>>> when declaring external prototypes, the author needs to declare the
>>>
>>>>> subset of the interface she intends to use by replicating those
>>>
>>>>> fields from the prototype declaration (cf X3D spec 4.4.5.2)
>>>
>>>>>
>>>
>>>>> What is the rationale behind this? Seem to make the implementation a
>>>
>>>>> little bit simpler, but since events that occure before the
>>>>> prototype
>>>
>>>>> has been resolved are ignored anyway, this is really just a little bit.
>>>
>>>>> However it complicates the use of external prototypes because it's a
>>>
>>>>> popular source of error (at least for my first steps with prototypes
>>>
>>>>> at times when maybe the error messages in then popular X3D browsers
>>>
>>>>> where improvable).
>>>
>>>>>
>>>
>>>>> But maybe I miss something.
>>>
>>>>>
>>>
>>>>> Best,
>>>
>>>>> Kristian
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org