<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 3/20/2016 5:46 PM, John Carlson
wrote:<br>
</div>
<blockquote
cite="mid:640ECA81-868F-4B3F-9697-82729E482193@gmail.com"
type="cite">
<pre wrap="">Thanks for commenting Leonard, I thought it was going to be left behind in the id/class discussion
</pre>
<blockquote type="cite">
<pre wrap="">On Mar 20, 2016, at 8:32 PM, Leonard Daly <a class="moz-txt-link-rfc2396E" href="mailto:web3d@realism.com"><web3d@realism.com></a> wrote:
could refer to all viewpoint nodes in the main scene. An X3D ROUTE that identified that string as the destination would change all viewpoints. While this is not hard to do (for example jQuery does this), it can cause considerable overhead if you have to check the entire scene graph for matching nodes on every animation step.
</pre>
</blockquote>
<pre wrap="">
Only check the scene graph when the members of the selection change.</pre>
</blockquote>
<br>
<br>
There are several ways the members can change:<br>
<br>
1) Classes are added to the ROUTE statement. This one is easy to
catch because it changes the ROUTE statement<br>
<ROUTE id='route1' ... toNode='.animationTransforms' ... /><br>
<br>
changes to<br>
<br>
<ROUTE id='route1' ... toNode='.animationTransforms
.animationViewpoints' ... /><br>
<br>
<br>
2) Classes are added to other nodes. This is harder because you need
to monitor all nodes for class attribute changes<br>
<Transform class='animation' ... >...</Transform><br>
<Viewpoint class='look-see' ... >...</Transform><br>
<ROUTE id='route1' ... toNode='.animation' .../><br>
<br>
changes to:<br>
<br>
<Transform class='animation' ... >...</Transform><br>
<Viewpoint class='look-see animation' ...
>...</Transform><br>
<ROUTE id='route1' ... toNode='.animation' .../><br>
<br>
<br>
3) Nodes are added to scene graph. Not too bad because somethings
need to be rebuilt or refreshed on node additions. Node removal is
similar.<br>
<Transform class='animation' ... >...</Transform><br>
<ROUTE id='route1' ... toNode='.animation' .../><br>
<br>
changes to:<br>
<br>
<Transform class='animation' ... >...</Transform><br>
<Viewpoint class='look-see animation' ...
>...</Transform><br>
<ROUTE id='route1' ... toNode='.animation' .../><br>
<br>
<br>
There are other cases that end up being similar to the above. My
concern is for the complexity that this may introduce. Under V3.x,
each edge of the ROUTE graph is defined by just one ROUTE statement
(I'm not sure if duplicate ROUTE statements were ever addressed), so
fans always require multiple statements with either a single
destination or source. If the goal is to make fans easier (and more
obvious) perhaps something like the following would be better:<br>
<br>
<ROUTE><br>
<from><br>
<node>DEF/id-node1-name</node><br>
<field>field1-name</field><br>
</from><br>
<from><br>
<node>DEF/id-node2-name</node><br>
<field>field2-name</field><br>
</from><br>
:<br>
:<br>
<from><br>
<node>DEF/id-nodeN-name</node><br>
<field>fieldN-name</field><br>
</from><br>
<to><br>
<node>DEF/id-node1-name</node><br>
<field>field1-name</field><br>
</to><br>
<to><br>
<node>DEF/id-node2-name</node><br>
<field>field2-name</field><br>
</to><br>
:<br>
:<br>
<to><br>
<node>DEF/id-nodeN-name</node><br>
<field>fieldN-name</field><br>
</to><br>
</ROUTE><br>
<br>
Or perhaps more compact versions:<br>
<ROUTE><br>
<from node='node1-name' field='field1-name' /><br>
<from node='node2-name' field='field2-name' /><br>
:<br>
:<br>
<from node='nodeN-name' field='fieldN-name' /><br>
<to node='node1-name' field='field1-name' /><br>
<to node='node2-name' field='field2-name' /><br>
:<br>
:<br>
<to node='nodeN-name' field='fieldN-name' /><br>
</ROUTE><br>
<br>
<br>
Having a fan extent be dynamically defined during run-time is an
interesting proposition. Sort of along the lines of an event
listener. That would mean any node that was interested in changing
needed to listen for events of certain types from selected sources.
This is a change in philosophy from the current of directed events.
<br>
<br>
Perhaps events need to have source IDs and possibly classes. Then
the transform field of a Transform (for example) node could listen
for all 'translation' events, or 'translation' events with a
particular ID. That would be much closer to how HTML events work. In
the communities current development methodology and philosophy,
events are created for a specific field of a specific node. This
change would require rethinking how events should be created. <br>
<br>
This topic is worthy of additional discussion and perhaps some
examples before understanding how to implement it.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:640ECA81-868F-4B3F-9697-82729E482193@gmail.com"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">My initial thought is to not go down this route; however, that just may be my concern on run-time performance and not being creative enough to see all of the good possibilities.
</pre>
</blockquote>
<pre wrap="">
Agreed. Let’s wait for a good use case. Necessity is the mother of invention. We can write a route expander in the meantime.
John
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
X3D Co-Chair<br>
Cloud Consultant<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>