<div dir="ltr">Proto expansion: when rendering freewrl uses the fields of the first node in the proto, and ignores the proto fields . When routing freewrl routes to the proto fields and ignores the proto first node. Is this correct behavior in web3d? That the first node is the interface for rendering, and the proto interface is the interface for routing?<div>-Doug</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Nov 9, 2025 at 7:33 PM GPU Group <<a href="mailto:gpugroup@gmail.com">gpugroup@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">"the first node" Thanks Michalis - I should know that sorry I forgot.<div>-Doug</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 9, 2025 at 5:33 PM Michalis Kamburelis <<a href="mailto:michalis@castle-engine.io" target="_blank">michalis@castle-engine.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="font-family:Arial,sans-serif;font-size:14px"><span>The first node within the prototype "expansion" (specified in <ProtoBody> in X3D XML encoding) is the node that effectively is inserted into the node graph in place of the <ProtoInstance>.</span><div><br></div><div><span>So to answer your question, I think it's just "the first node".</span></div><div><br></div><div><span>Here's an example of prototype extending a built-in Material node, since you mentioned this example: <a rel="noreferrer nofollow noopener" href="https://github.com/castle-engine/demo-models/blob/master/x3d/proto_of_material.x3d" target="_blank">https://github.com/castle-engine/demo-models/blob/master/x3d/proto_of_material.x3d</a> . It should be rendered as a red box. (And it is, by both FreeWRL and Castle Model Viewer, just checked :) ).</span></div><div><br></div><div><span>Regards,</span></div><span>Michalis</span><br></div>
<div style="font-family:Arial,sans-serif;font-size:14px">
    <div>
        
            </div>
    
            <div>
        
            </div>
</div>
<div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div>
        On Sunday, November 9th, 2025 at 15:23, GPU Group via x3d-public <<a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a>> wrote:<br>
        <blockquote type="cite">
            <div dir="ltr"><div>Builtin - nodes defined in x3d specs</div><div>Q. how to declare / detect what builtin node type a ProtoDeclare extends?</div><div>Thanks,</div><div>-Doug Sanden</div><div>Normally if we want to change parameters on a builtin node, we tinker directly with the builtin node in the scene with routes and scripts.</div>In theory builtin nodes are extensible -- a ProtoDeclare can wrap a builtin, IS all the fields, and add some spice with a Script node inside the proto that updates some fields on each frame. But how is the x3d browser code supposed to detect what builtin node type is being extended?<div>For example, Shape.appearance.material can take different types of material nodes: UnlitMaterial, Material, PhysicalMaterial. In browser application code there's different handling of each type:</div><div>if mat.type == UNLIT then</div><div>...</div><div>else if mat.type == MATERIAL then</div><div>...</div><div>else if mat.type == PHYSICAL then</div><div>...</div><div>endif</div><div>But a ProtoInstance has a ProtoDeclare type which doesn't give a hint as to which builtin type the ProtoDeclare is extending.</div><div>Q1. How is the code supposed to detect which builtin type to process?</div><div>Q2. If a ProtoDeclare extends a previous ProtoDeclare, which extends a builtin type, and assuming single-inheritance chain from builtin, how can browser code detect the original bultin being extnded?</div><div><br></div></div>

        </blockquote><br>
    </div></blockquote></div>
</blockquote></div>