[x3d-public] CSS st5yle usage for Routes [was: id attribute proposal]

Sun Mar 20 18:20:31 PDT 2016

On 3/20/2016 5:46 PM, John Carlson wrote:
> Thanks for commenting Leonard, I thought it was going to be left behind in the id/class discussion
>
>> On Mar 20, 2016, at 8:32 PM, Leonard Daly <web3d at realism.com> 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.
>>
> Only check the scene graph when the members of the selection change.

There are several ways the members can change:

1) Classes are added to the ROUTE statement. This one is easy to catch 
because it changes the ROUTE statement
<ROUTE id='route1' ... toNode='.animationTransforms' ... />

changes to

<ROUTE id='route1' ... toNode='.animationTransforms 
.animationViewpoints' ... />

2) Classes are added to other nodes. This is harder because you need to 
monitor all nodes for class attribute changes
<Transform class='animation' ... >...</Transform>
<Viewpoint class='look-see' ... >...</Transform>
<ROUTE id='route1' ... toNode='.animation' .../>

changes to:

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.
<Transform class='animation' ... >...</Transform>
<ROUTE id='route1' ... toNode='.animation' .../>

changes to:

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:

<ROUTE>
     <from>
         <node>DEF/id-node1-name</node>
        <field>field1-name</field>
     </from>
     <from>
         <node>DEF/id-node2-name</node>
        <field>field2-name</field>
     </from>
     :
     :
     <from>
         <node>DEF/id-nodeN-name</node>
        <field>fieldN-name</field>
     </from>
     <to>
         <node>DEF/id-node1-name</node>
        <field>field1-name</field>
     </to>
     <to>
         <node>DEF/id-node2-name</node>
        <field>field2-name</field>
     </to>
     :
     :
     <to>
         <node>DEF/id-nodeN-name</node>
        <field>fieldN-name</field>
     </to>
</ROUTE>

Or perhaps more compact versions:
<ROUTE>
     <from node='node1-name' field='field1-name' />
     <from node='node2-name' field='field2-name' />
         :
         :
     <from node='nodeN-name' field='fieldN-name' />
     <to node='node1-name' field='field1-name' />
     <to node='node2-name' field='field2-name' />
         :
         :
     <to node='nodeN-name' field='fieldN-name' />
</ROUTE>

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.

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.

This topic is worthy of additional discussion and perhaps some examples 
before understanding how to implement it.

Leonard Daly

>
>> 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.
> 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
>
>

-- 
*Leonard Daly*
X3D Co-Chair
Cloud Consultant
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160320/14f342ca/attachment-0001.html>