[x3d-public] Simplifying ProtoInstance nodes
John Carlson
yottzumm at gmail.com
Sat May 10 16:49:49 PDT 2025
One might consider putting a Group inside a Switch inside a Proto called
“Group.” I would have to see an example that someone has built to see
usefulness of this. Probably some kind of L-system could be done:
https://en.m.wikipedia.org/wiki/L-system
I’m imagining some kind of Switch where the whichChoice is decremented to
-1 which would be the leaf of the plant.
One might also think of Fractal compression/decompression.
John
On Sat, May 10, 2025 at 6:37 PM John Carlson <yottzumm at gmail.com> wrote:
> Perhaps there danger in recursively defined nodes in Andreas’ Group case.
> That is, a Group used in a ProtoBody of a Proto. We also have to think of
> two Protos with the same name, which is not allowed within the same
> namespace.
>
> Maybe put a Group in the ProtoBody in Andreas’ Group example and see
> what happens. I’m too “scared,” I don’t want to blow up my smartphone.
> But perhaps the inside of ProtoBody is in a different namespace, and
> problems are avoided.
>
> If you guys already know how to debug this from an expert point of view,
> great. Seems confusing. My tendency would be to go with Holger’s idea, no
> override. If someone really wants to do this, they can edit X_ITE or X3DOM
> to do what they want.
>
> Agreed that expert authors may want to do this. But they are experts.
> AFAIK, recursion is not allowed in X3D.
>
> John
>
>
> On Sat, May 10, 2025 at 4:27 PM Andreas Plesch via x3d-public <
> x3d-public at web3d.org> wrote:
>
>> I actually think I have never tested when a Proto has the same name as a
>> native node in x3dom.
>>
>> Here is an example for 'Box':
>>
>>
>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/5e2c6068d0495605198f9a20254c7519/raw/91ee41a9afbb8ee9dec5952108bf13bdc41f4de0/ProtoBoxCollision.x3d
>>
>> It appears that the Proto redefinition takes precedence.
>>
>> Here is an example for 'Group':
>>
>>
>> https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/5e2c6068d0495605198f9a20254c7519/raw/3b7a53131c0c890b9672b38ae083c81c8524d60e/ProtoNativeCollisionTest.x3d
>>
>> This is more complicated but I think the Proto definition still takes
>> precedence except that now only the first child of the type transform is
>> rendered.
>>
>> I would suggest letting browser behaviour for that case remain undefined
>> to discourage authors to somehow cleverly apply such a feature.
>>
>> Andreas Plesch
>> Waltham, MA 02453
>>
>> On Sat, May 10, 2025, 3:39 PM <x3d-public-request at web3d.org> wrote:
>>
>>> Date: Sat, 10 May 2025 21:37:47 +0200
>>> From: Holger Seelig <holger.seelig at yahoo.de>
>>> To: X3D <x3d-public at web3d.org>
>>> Subject: Re: [x3d-public] Simplifying ProtoInstance nodes
>>> Message-ID: <67EB2216-BC2C-4A50-9E57-122241628399 at yahoo.de>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> There is another drawback which already exist in VRML encoding. What
>>> take precedence if a PROTO is named as a build-in node. Consider a PROTO
>>> named Box with a Sphere as root node. What is happening if a Box is now
>>> instantiated?
>>>
>>> PROTO Box []
>>> {
>>> Sphere {}
>>> }
>>>
>>> Shape {
>>> Box {}
>>> }
>>>
>>> This behaviour is not handled by the specification, but X_ITE does the
>>> following: build-in nodes will take precedence over over PROTO nodes, it
>>> will still display a Box node. Don?t know what Caste or X3DOM does. With
>>> current XML encoding this is very cleared and there is no prob at all. But
>>> in VRML encoding or with XML ?short syntax? this may be worth a spec
>>> comment.
>>>
>>> Best regards,
>>> Holger
>>>
>>> --
>>> Holger Seelig
>>> Leipzig, Germany
>>>
>>> holger.seelig at yahoo.de
>>> https://create3000.github.io/x_ite/
>>> https://patreon.com/X_ITE
>>>
>>>
>>>
>>> > Am 10.05.2025 um 20:44 schrieb Brutzman, Donald (Don) (CIV) via
>>> x3d-public <x3d-public at web3d.org>:
>>> >
>>> > +1 on all counts, thanks for thoughtful consideration Michalis.
>>> >
>>> > Further considerations are always welcome.
>>> >
>>> > Next week Dick and I will review comments, then consider a Mantis
>>> issue and draft prose addition to X3D XML Encoding.
>>> >
>>> > 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
>>> https://faculty.nps.edu/brutzman
>>> >
>>> >
>>> > From: Michalis Kamburelis
>>> > Sent: Saturday, May 10, 2025 11:38 AM
>>> > To: Extensible 3D (X3D) Graphics public discussion
>>> > Cc: Brutzman, Donald (Don) (CIV)
>>> > Subject: Re: [x3d-public] Simplifying ProtoInstance nodes
>>> >
>>> > I think this short form (in XML encoding) makes sense, and Castle Game
>>> Engine / Castle Model Viewer could support it too.
>>> >
>>> > It makes XML encoding and classic encoding more consistent: you can
>>> use PROTO to define a new node, and then use the new node with the same
>>> syntax as "built-in nodes". This is already true for classic encoding, it's
>>> nice to bring this feature to XML encoding.
>>> >
>>> > Don has already expressed the important drawback of this "short form":
>>> such XML will not validate. I mean, it will validate in X3D-specific tools
>>> like "castle-model-converter --validate .." (once we add support for it),
>>> but the general XML validation using XML Schema has no way of validating
>>> it. You cannot tell in XML schema "this XML element name is valid, if
>>> defined by some XML attribute elsewhere". I'm guessing this was the whole
>>> reason why ProtoInstance, fieldValue etc. were invented in XML encoding.
>>> >
>>> > I'm guessing in JSON X3D encoding, the consideration will be similar:
>>> it can be implemented, but the resulting file will not validate with JSON
>>> schema ( https://json-schema.org/ ).
>>> >
>>> > Anyhow, if we're all fine with accepting this drawback, then we sure
>>> can go ahead and add it to spec :) As long as "long form" remains
>>> available, and thus tools like XML schema and JSON schema remain useful, I
>>> think it makes sense to have this choice.
>>> >
>>> > Regards,
>>> > Michalis
>>> >
>>> > sob., 10 maj 2025 o 18:38 Brutzman, Donald (Don) (CIV) via x3d-public <
>>> x3d-public at web3d.org <mailto:x3d-public at web3d.org>> napisa?(a):
>>> > Thanks for the interesting, innovative discussion. Excerpting the
>>> example:
>>> >
>>> >
>>> https://create3000.github.io/x_ite/tutorials/creating-new-node-types/#using-prototyped-nodes
>>> >
>>> > _________________________
>>> > XML Encoding
>>> > 1
>>> > 2
>>> > 3
>>> > 4
>>> > 5
>>> > 6
>>> > 7
>>> > 8
>>> > 9
>>> > <!-- Official Syntax -->
>>> > <ProtoInstance name='BouncingBall'>
>>> > <fieldValue name='cycleInterval' value='2'/>
>>> > <fieldValue name='bounceHeight' value='3'/>
>>> > </ProtoInstance>
>>> > <!-- Short Syntax -->
>>> > <BouncingBall
>>> > cycleInterval='2'
>>> > bounceHeight='3'/>
>>> > Classic VRML Encoding
>>> > 1
>>> > 2
>>> > 3
>>> > 4
>>> > BouncingBall {
>>> > cycleInterval 2.0
>>> > bounceHeight 3.0
>>> > }
>>> > _________________________
>>> >
>>> > One drawback with the "short" XML syntax is that it will not pass XML
>>> DOCTYPE or XML Schema validation, although it still must conform to XML
>>> well-formed rules. Additional tool-specific capabilities can check for
>>> such correctness during parsing, of course. Avoiding XML validation
>>> relaxes quality assurance (QA) for the entire scene, not just that
>>> prototype instance, and so use of the short form should be considered
>>> carefully.
>>> >
>>> > Of course there is much merit too, not least of which are readability
>>> and consistency with other XML-encoded nodes.
>>> >
>>> > As it turns out, now is a good time to consider such a change to the
>>> X3D Standards suite. We have highly mature documents defining X3D
>>> encodings using XML and ClassicVRML syntax. Conceivably a "short" form for
>>> ProtoInstance will carry over satisfactorily for JSON and other encodings
>>> as well, when we get to them this fall.
>>> >
>>> > If X_ITE and X3DOM already handle this form, and if Castle Model
>>> Viewer (Castle Game Engine) is also supportive, I'm not yet seeing any
>>> blockers to adoption. Further implementation and evaluation of course will
>>> be useful
>>> >
>>> > Reference and specific clause that would need modification:
>>> >
>>> > X3D XML Encoding 4.0 <
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/X3D_XML.html>
>>> revision 19776-1
>>> > 4.3.3.2 ProtoInstance node and fieldValue statement syntax
>>> >
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-1v4.0-WD1/Part01/concepts.html#ProtoInstanceAndFieldValueStatement
>>> >
>>> > Probably no changes needed:
>>> >
>>> > X3D Classic VRML Encoding 4.0 <
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/X3D_ClassicVRML.html>
>>> revision 19776-2
>>> > 4.3.3.2 Prototype instances and field value initialization syntax
>>> >
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19776-2v4.0-WD1/Part02/concepts.html#ProtoInstanceAndFieldValueStatement
>>> >
>>> > X3D Architecture 4.1 <
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/Architecture.html>,
>>> revision 19775-1
>>> > 4.4.4 Prototype semantics
>>> >
>>> https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4.1-CD//Part01/concepts.html#PrototypeSemantics
>>> >
>>> > Thanks for careful consideration of this potential capability. All
>>> feedback welcome.
>>> >
>>> > Have fun with X3D extensibility! ?
>>> >
>>> > 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
>>> https://faculty.nps.edu/brutzman
>>> >
>>> >
>>> > From: x3d-public on behalf of Holger Seelig via x3d-public
>>> > Sent: Saturday, May 10, 2025 1:13 AM
>>> > To: X3D
>>> > Cc: Holger Seelig
>>> > Subject: Re: [x3d-public] Simplifying ProtoInstance nodes
>>> >
>>> > This is already possible if you use the ?short syntax? of a proto
>>> instance:
>>> >
>>> >
>>> https://create3000.github.io/x_ite/tutorials/creating-new-node-types/#using-prototyped-nodes
>>> >
>>> > You can use this in X_ITE, but also in X3DOM.
>>> >
>>> > Best regards,
>>> > Holger
>>> >
>>> > --
>>> > Holger Seelig
>>> > Leipzig, Germany
>>> >
>>> > holger.seelig at yahoo.de <mailto:holger.seelig at yahoo.de>
>>> > https://create3000.github.io/x_ite/
>>> > https://patreon.com/X_ITE
>>> >
>>> >
>>> >
>>> > Am 10.05.2025 um 05:55 schrieb John Carlson via x3d-public <
>>> x3d-public at web3d.org <mailto:x3d-public at web3d.org>>:
>>> >
>>> > My thought is to replace ?ProtoInstance? tags with ?MenuItem? tags,
>>> and fieldValue statements with attributes, but I?ve not done that before.
>>> My goal is to make the model more accessible to screen readers.
>>> >
>>> > Any examples are welcome.
>>> >
>>> > See attached link and model.
>>> >
>>> > John
>>> >
>>> > ---------- Forwarded message ---------
>>> > From: John Carlson <yottzumm at gmail.com <mailto:yottzumm at gmail.com>>
>>> > Date: Thu, Mar 6, 2025 at 4:35?PM
>>> > Subject: Latest cleaned Jin FACS (needs metadata)
>>> > To: Don Brutzman <brutzman at nps.edu <mailto:brutzman at nps.edu>>, Joe D
>>> Williams <joedwil at earthlink.net <mailto:joedwil at earthlink.net>>
>>> >
>>> >
>>> > Attached.
>>> >
>>> > And:
>>> >
>>> https://create3000.github.io/x_ite/playground/?url=https://raw.githubusercontent.com/coderextreme/ci2had/refs/heads/main/resources/CleanedYouClocks.x3d
>>> >
>>> > John
>>> > <CleanedYouClocks.x3d>_______________________________________________
>>> > 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 <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/20250510/e81345db/attachment.html
>>> >
>>>
>>> ------------------------------
>>>
>>> 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 194, Issue 27
>>> *******************************************
>>>
>> _______________________________________________
>> 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/20250510/9e3f3841/attachment-0001.html>
More information about the x3d-public
mailing list