prototypes

after finding whole swathes of geometry missing when viewed in
BSContact (7.107)

i wrote a basic test case; ( see below )

expecting to see,

init:b
init:b
init:a
init:c

actually got;

init:b
init:c

it appears only the first instance of any proto is actually built, and
also that proto nodes in fields are ignored!!

which obviously makes protos useless, and since protos/classes really
are the fundamental structural element in any language, this means
that BSContact is only really supporting VRM, the L is basically
missing.

which makes me wonder, is there any mechanism for preventing a
browser from claiming support for the standard, when it falls so far
short, without this the main mechanism for maintaining compliance is
missing?

although, checking the X3D spec., prototyping is optional in core 1,
which means 'iteractive' and 'exchange' dont require it.

so this is kind of X3D 'interactive' and X3D 'exchange' compliment but
not VRML complaint, although to be pedantic, in these lower profiles
the syntax shouldn't be there, so it clearly is meant to work, which
probably means its not complient with anything.

test
~~~~

#VRML V2.0 utf8
PROTO a []{
Script {
url ["javascript:function initialize(){print ('init:a');} "]
}
}

PROTO b []{
Script {
url ["javascript:function initialize(){print ('init:b');} "
]
}
}

PROTO c [field SFNode fieldNode NULL ]{
Script {
url ["javascript:function initialize(){print ('init:c');} "
]
}
}

b {}
b {}
c {fieldNode a {}}

> expecting to see,

> init:b
> init:b
> init:a
> init:c

> actually got;

> init:b
> init:c

> it appears only the first instance of any proto is actually built

Well, if you would like to test that, you should not use the initialize()
function, which should be in fact built only once...

> PROTO b []{
> Script {
> url ["javascript:function initialize(){print ('init:b');} "
> ]
> }
> }

so long
MUFTI
--
Während der Tonhöhe Wenn der Krug die Kugel auslöst, können
Sie das .BAT bunt Ihren Schwung oder beendet,, wenn Sie erweitertes
Batting verwenden Sie können Ihren Schwung anstreben, und das .BAT
bunt Ihren Schwung oder beendet,, swing. Artikel-ID: 187917 Version: 1.0

> initialize()
> function, which should be in fact built only once...


why? each instance contains a new script, each could be different
depending on the contents of the fields of the proto, (this is the
point of prototypes.) it makes no sense to only initialize the first
one, it would mean simply reordering the code would change the
content, ridiculous.

anyway when tested in Cortona ( not latest version) all the instances
initialize their scripts, BUT, the field located instance initializes
after the parent node does, so the parent cant see what happened in
the field initialization , which is also wrong!!

On May 4, 3:54*am, simon <simon.pl...@googlemail.com> wrote:
> after finding whole swathes of geometry missing when viewed in
> BSContact (7.107)
>
> i wrote a basic test case; ( see below )
>
> expecting to see,
>
> init:b
> init:b
> init:a
> init:c
>
> actually got;
>
> init:b
> init:c
>
> it appears only the first instance of any proto is actually built, and
> also that proto nodes in fields are ignored!!

Actually your example is flawed, Cortona is the non spec complient
one.

>PROTO c [field SFNode fieldNode NULL ]{
> Script {
> url ["javascript:function initialize(){print ('init:c');} "
> ]
>
> }
> }

Note how 'fieldNode' is never part of the scene graph !

You needed to write something like this:
PROTO c [field SFNode fieldNode NULL ]{
Group {
children [
DEF G Group {}
Script {
directOutput TRUE # needed for contact, but should be here
anyway !
field SFNode fieldNode IS fieldNode
field SFNode g USE G
url ["javascript:function initialize()
{g.children[0]=fieldNode; print ('init:c');} "
]

}
]
}
}


Also note that contact needs directOutput TRUE if you have a node
where internal scripting creates a unique node. Its an optimization
feature so multiple static geometry PROTO instances get treated as DEF/
USE internally. Nodes where an exposedField or field 'IS' mapped to
say a Material field don't need this change btw.

Hence in your example, b only runs once (the 2nd one is a pointless
duplicate), and a is not even part of the scene so never runs at all.

been having a think,

realise my example wasn't a correct cutdown version of the problem i
was having, its a little more complex, the good news is i found a fix.

what i am doing is using a node (proto) in a field of another node
(also a proto) that changes the construction of that node in a complex
way, ie the field node contains a node containing a script that does
an aspect of the build of the main geometry node, so is very flexible.

anyway, i found the issue;

the 'inner' node has a 'parameter' node field, the 'outer' node uses
this 'parameter' node for its construction, what was happening was
that the changes to the 'parameter' node weren't being seen by the
'outer' node, i thought is was to do with the scripts, but it wasn't,
the 'inner' node could change, and see the changes to the 'parameter'
node, but the 'outer' node was only seeing the unitialalised, pre set
up, 'parameter' node, it turned out that there are TWO 'parameter'
nodes, because its being passed by value, so its only a copy of the
'parameter' node being modified by the 'inner' nodes script. To fix
this all that was needed was to set the 'inner' nodes parameter field
as exposed, then its passed by reference and it works.

theres an example using this technique with a block building proto
here;

http://trialpage.googlepages.com/bocks

been having a think;

i can see what you are saying;

"if there is no 'IS' in the proto body, then all the instances must be
the same."

however;

i been using the mental image of;

"proto's absorb code duplication, so have the ability to be unrolled
to an equivilant"

it seems these two concepts lead to two possabilities off script
initialization, and i can not see from the specification which is
correct!!

> it seems these two concepts lead to two possibilities of script
> initialization, and i can not see from the specification which is
> correct!!


now found this in spec.

<p>
4.4.4.3 PROTO definition semantics

A prototype definition consists of one or more nodes, nested PROTO
statements, and ROUTE statements. The first node type determines how
instantiations of the prototype can be used in an X3D file. An
instantiation is created by filling in the parameters of the prototype
declaration and inserting copies of the first node (and its scene
graph) wherever the prototype instantiation occurs.
</p>

which is clear that the unrolling semantic is the correct one, so each
script node requires initialization, so contact is wrong. obviously
this also applies to "finalize".

so in these cases a dummy 'IS' will be needed as a work round for
Contact.

>
> Note how 'fieldNode' is never part of the scene graph !


well yes, default field values are not themselves in the scene tree,

but the proto scope starts at the start of the definition, not the
start of the interface, (argued about this issue before) so the fields
and the default values are in the surrounding scope, so you can DEF/
USE to the default values of fields of node type in the interface, so
you might refer from a node in the scene tree to a default field
value, and if it were a script node it would need initialising,

although this is a bit contrived, and would hardly ever happen, and
you could argue it doesn't need initialising if it isn't actually
USEd, you also have to watch out for side effects outside the scene
tree, like network access, so this should be clear, but basically the
specification isn't.

>
> http://trialpage.googlepages.com/bocks


BTW althouht this works in contact as is, i've discovered it breaks
when its inlined, so we have yet another Contact bug, starting to feel
like pushing-water-up-hill, this.