[x3d-public] ProtoBody completeness in nested Protos
Andreas Plesch
andreasplesch at gmail.com
Mon Apr 25 12:09:06 PDT 2022
Hi Doug,
Thank you for your response.
> Date: Mon, 25 Apr 2022 07:09:14 -0600
> From: GPU Group <gpugroup at gmail.com>
>
> freewrl loads extern proto scenes as whole scene files, but as 'dead'
> scenery like a library file: in binary form, ready to binary deep copy
> parts to live scenery, but node initialization functions not yet
> called, and not rendered. Subsequent # references to the same scene file
> use the same loaded library scene. So any ProtoDeclares outside the
> ProtoBody would be resolved.
I think the issue in the CircleFishLod prototype is not directly
related to extern proto use, but only to how the local ProtoDeclare
definition needs to reach into the surrounding Scene. It sounds like
freewrl allows for that mixing of Execution Contexts, assuming that
the CircleFishLod proto works in freewrl.
A stress test example would be a Scene which has two Protos, A and B.
A is a simple Proto with the name "Joe". The scene uses it in an instance later.
B is a nested Proto which internally uses another Proto. This internal
Proto is also named "Joe" and has both a ProtoDeclare and instances
within B. The scene then uses B in an instance later.
How should a browser resolve which ProtoDeclaration to use for the
internal ProtoInstance "Joe" ? Which one would freewrl choose ? The
first one it finds ?
Perhaps it is time to draft such a test.
Thanks, Andreas
PS: rough draft
<ProtoDeclare name='Joe'>
<ProtoBody red sphere />
</ProtoDeclare>
<ProtoDeclare name='nestedBox'>
<ProtoBody>
<ProtoDeclare name='Joe'>
<ProtoBody blue box />
</ProtoDeclare>
<ProtoInstance name='Joe' />
</ProtoBody>
</ProtoDeclare>
<ProtoInstance name='Joe' />
<ProtoInstance name='nested' />
Should display a red sphere and blue box.
> -Doug
> PS this relates to:
>
> PROTOTYPE STYLE IMPORTS
>
> I had mentioned a prototype style import for gltf use:
>
> Shape { url=?library.gltf#shapeName? }
>
> Similar to how we load extern protos as a whole ?dead? scene, and then do
> binary deep copies where used in the live scene to make live.
>
> But interestingly, the same goes for x3d scenery ? don?t need glTF, don?t
> need extern protos in library scene, don?t need Inline or IMPORT.
>
> So the concept could be tested first with x3d scenery.
>
> Shape { url=?library.x3dv#shapeName }
>
> And then extended to gltf.
>
> /PROTOTYPE STYLE IMPORTS
>
> On Sun, Apr 24, 2022 at 10:43 PM Brutzman, Donald (Don) (CIV) <
> brutzman at nps.edu> wrote:
>
> > Actually please look a little more closely at that (admittedly tricky)
> > example.
> >
> > * CircleFish is an ExternProto, separately defined in another file
> > * CircleFishLod is a ProtoDeclare defined in that first file,
> > CircleFishLodPrototype.x3d
> > * CircleFishLod ProtoBody contains two ProtoInstance copies of CircleFish
> > * CircleFishLod ProtoDeclare is then followed by a CircleFishLod
> > ProtoInstance (again in CircleFishLodPrototype.x3d)
> >
> > So I would expect an X3D Browser to
> >
> > a. load ExternProtoDeclare CircleFish
> > b. build ProtoDeclare CircleFishLod
> > c. create inner ProtoInstance CircleFish for use
> > d. create outer ProtoInstance CircleFishLod
> >
> > Order of steps might vary a bit, but those are the dependencies. Good luck
> > sir.
> >
> > 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 https://
> > faculty.nps.edu/brutzman
> >
> > -----Original Message-----
> > From: x3d-public <x3d-public-bounces at web3d.org> On Behalf Of Andreas
> > Plesch
> > Sent: Sunday, April 24, 2022 9:08 PM
> > To: X3D Graphics public mailing list <x3d-public at web3d.org>
> > Subject: [x3d-public] ProtoBody completeness in nested Protos
> >
> > ProtoDeclarations may use ProtoInstances of other Protos inside their
> > ProtoBody definitions.
> >
> > For example, the CircleFishLod proto here:
> >
> >
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fx3dgraphic
> > s.com
> > %2Fexamples%2FX3dForWebAuthors%2FKelpForestExhibit%2FCircleFishLodProto
> > typeIndex.html&data=05%7C01%7Cbrutzman%40nps.edu
> > %7C0b4a867ba9874e371f9b0
> >
> > 8da267152fa%7C6d936231a51740ea9199f7578963378e%7C0%7C0%7C637864565880708349%
> >
> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> >
> > LCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=upr4eckI8axT7MO5fAUvAWfyBzUJfhTwqcp
> > BuH7tZjc%3D&reserved=0
> >
> > uses ProtoInstances of the CircleFish proto.
> >
> > A more extreme case of nesting is:
> >
> >
> > https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PRO
> > TO/fivedeepnestingIndex.html
> > <https://www.web3d.org/x3d/content/examples/ConformanceNist/Miscellaneous/PROTO/fivedeepnestingIndex.html>
> >
> > where Proto1 uses ProtoInstance of Proto2 inside its ProtoBody. Proto2
> > itself uses a ProtoInstance of Proto3 inside its ProtoBody. And so on to
> > five levels deep.
> >
> > The second example with the deep nesting currently works with x3dom but the
> > seemingly simpler CircleFishLod proto does not.
> >
> > The reason is that x3dom expects the complete definition of a proto to be
> > contained in its ProtoBody. However, The CircleFishLod proto only contains
> > the CircleFish ProtoInstances in the body but not the associated CircleFish
> > ProtoDeclaration which for some reason occurs outside the CircleFishLod
> > ProtoBody (and outside the CircleFishLod ProtoDeclaration).
> >
> > Expecting the ProtoBody to be complete and self-contained seems rather
> > natural. Is x3dom too strict in this regard, or is there an oversight in
> > the
> > example ? There is not much guidance in the spec., if any.
> >
> > Thanks, Andreas
> >
> > --
> > Andreas Plesch
> > Waltham, MA 02453
> >
> > _______________________________________________
> > x3d-public mailing list
> > 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/20220425/fdcca17c/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 25 Apr 2022 15:14:25 +0000
> From: "Brutzman, Donald (Don) (CIV)" <brutzman at nps.edu>
> To: Andreas Plesch <andreasplesch at gmail.com>
> Cc: "x3d at web3d.org" <x3d at web3d.org>, Spec Feedback
> <spec-comment at web3d.org>, "X3D Public Mailing List
> (x3d-public at web3d.org)" <x3d-public at web3d.org>, "Brutzman, Donald
> (Don) (CIV)" <brutzman at nps.edu>
> Subject: Re: [x3d-public] [x3d] Spec Comment by on 19775-1: X3D
> Architecture - V4.0: component support needed for glTF inline loading
> conversion
> Message-ID:
> <BY3PR13MB48844D178FEBD3BCA8221B51C4F89 at BY3PR13MB4884.namprd13.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> [cc: x3d-public]
>
> Thanks for insightful comment. Happy to modify this statement to list all
> appropriate components, possibly Immersive profile.
>
> Michalis, do you have any opinions from writing your glTF->X3D conversion
> code?
>
> It helps to know full coverage. If there is a glTF test file that includes
> all constructs, that would also be helpful to convert and add to our
> architecture.
>
> 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 https://
> faculty.nps.edu/brutzman
>
> -----Original Message-----
> From: x3d <x3d-bounces at web3d.org> On Behalf Of Spec Feedback
> Sent: Thursday, April 21, 2022 12:47 PM
> To: x3d at web3d.org
> Subject: [x3d] Spec Comment by on 19775-1: X3D Architecture - V4.0
>
> -- Submitter indicates that this comment may be public: *Yes* --
>
> Comment on 19775-1: X3D Architecture - V4.0
>
> https://www.web3d.org/documents/specifications/19775-1/V4.0/Part01/component
> s/networking.html#X3DUrlObject
>
> -----------------
> "Support for loading glTF assets (see 2.[GLTF]) also requires support for
> Shape component level 2 and Lighting component level 4."
>
> Many different data fragments may be contained in the current standard gltf
> asset structure, even animation data, so maybe also more general statement?
>
>
>
> -----------------
>
> Submitted on Thursday, 2022, April 21 - 12:47pm by (Joe D Williams )
> IP: 12.206.82.58
>
> See: https://www.web3d.org/node/1694/submission/5663
>
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5353 bytes
> Desc: not available
> URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220425/1630c2b4/attachment.p7s>
>
> ------------------------------
>
> 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 157, Issue 93
> *******************************************
--
Andreas Plesch
Waltham, MA 02453
More information about the x3d-public
mailing list