Re: knotting, knitting, weaving and traffic flow

Fascinating examples Olaf. The word in English is similar: "tetrahedron."

Short of "an animatable z-index property with values either large integers 
or floats" which would pretty much give us 3D, I think maybe just a simple 
binary: "above" or "below" allowing content to declare its intention to be 
in one of two layers (maybe as subcommands of path) would give a fair amount 
of expressiveness without having to carve out all of three D.

A knot when represented as a planar four regular graph is traversable by a 
"forward walk." By that I mean: since it is planar the edges of each node 
can be oriented and labeled in a clockwise fashion. Then as we walk from one 
node to the next, always choose the forward path (instead of turning left or 
right). The string (1234516375862748) contains each node twice and in the 
context of each of its four neighbors along the specified Eulerian 
trail/forward walk. For each node, we need then only to indicate which of 
its occurrences is "above" and which is "under" ,  The it is just a matter 
of figuring out coordinates for those nodes and arcs that join them 
smoothly. If the rendering engine could simply follow the forward walk along 
the arcs penning up and penning down the appropriate stroke-width and angle 
from the intersections, wouldn't that do it?

cheers
David
----- Original Message ----- 
From: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
To: <www-svg@w3.org>; <ddailey@zoominternet.net>
Sent: Sunday, October 24, 2010 1:54 PM
Subject: re: knotting, knitting, weaving and traffic flow


> Hello,
>
>
> well due to my (german) tutorial about this issue there are different
> ways to manage this. Whether it can be considered trivial or not depends 
> on
> the individual situation and on the patience of the author ;o)
>
> a) clip, mask and maybe some other tricks may work.
> For such a simple situation the simplest way is maybe to put the street
> (as disjoined paths), the motion path (without disjoined segments)
> and the car into a defs element and reference street and car with
> some use elements.
> Calculate the times for the critical bridge points.
> Animate the XLink:href of the use elements with these times to
> switch what is rendered on top for the related times.
> With this method I manage for example to simulate a 3D-rotation
> of a star tetraeder (is this the name in english as well?) including
> a spherical projection:
> http://hoffmann.bplaced.net/svgueb/sterntetraeder2.php
> (Well - if there are poblems with the animation, this only indicates
> timing bugs in the used viewer or performance problems of the
> CPU).
> Other objects, same approach:
> http://hoffmann.bplaced.net/svgueb/dodekaeder2.php
> http://hoffmann.bplaced.net/svgueb/tetraeder2.php
>
> For them the right order is simply done by PHP sorting using
> the center of each surface to create the values lists for the
> animation of the hrefs of the use elements.
> For your street sample it should be even simpler like for this one:
> http://hoffmann.bplaced.net/svgueb/umrunden1.php
> (It is not just simpler, if uses another approach, because there
> are viewers having problems with a massive animation of
> XLink:href).
>
> b) see a) use another path without gaps. There is no need
> to create the graphical presentation of the street in the same
> way than the motion path.
>
> c.1) If there are  knot theoreticians interested in SVG, would be
> interesting to hear from them how to solve such rendering order
> problems in a simple way ;o)
>
> c.2) I think, there is no general solution for SVG1.1,
> if you have a larger amount of objects, for example a model of
> the solar system.
> For such a problem one can manage to keep the motion along
> the paths simple for each planet, however the intended timing of
> the rendering order can be a complex problem, depending on
> the complexity of the model (how many objects like dwarf planets
> etc are in the model).
> To solve such a problem in general,
> one needs something like an animatable z-index property with
> values either large integers or floats.
>
> Olaf
>
>

Received on Sunday, 24 October 2010 19:57:57 UTC