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, 

Not really, because still the author has to calculate the z-index for
separated paths and to create a values lists for the paths to animate 
the href of XLink. Still a lot of work that will prevent that many people 
use this just for fun (with the result, that viewers stuck into rendering of
only decorative animated complex 3D objects ;o)

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

If you have more than two objects, with only a binary information you 
have to build a larger amount of pairs to determine for each pair, what
is on top and what is below and than you have to do the same for
a pair of pairs and so on - works as long as you can build such pairs
for example in a solar system model this may work with sun+planet+moon,
however, with more objects already for such a simple system it can be 
very complex to get the declarative animation right with just pairwise 
binary information.

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

Sure, if you have exactly one path, it is no problem to know which point is
before/under and which one after/above. There is always a parametrisation
for all path segments in SVG. This can allow in your example to paint the
street with one path without gaps at the self intersecting areas.
However the central reservation and the animated car are already other 
objects in the source code.
This means at least that one has to spend more than one attribute/property
on one element to provide the information, that they are somehow related
for rendering. We need some XML presentation of the information, which
object is on top and which is below for each intersecting area.

The more difficult problem occurs with the finite size of your street.
What happens, if two non local areas of the path come only close
together without intersection? The streets/strokes might still overlap,
there is only an indirect information about this taking into account the
path structure and the stroke-width. This is already more difficult to
determine than an intersection point.
The solution has to be simple enough to have a simple XML presentation,
a simple explanation how to implement it and something that a simple
program like our viewers can manage fast enough with limited CPU 
resources ;o) 

And previous discussions on how already existing stroke properties 
work together resulted (only) in an information in SVGT 1.2, that
this is basically undefined. To have this information of top/below within
one path can a complete new approach to care about paths resulting
in complete new graphical libraries - well finally not really bad, because
the current results for stroke property combinations are already almost
arbitrary, but it is maybe hard to get this specified and implemented, 
if this did not work for already existing properties ;o)

The approach with z-index is somehow simpler, because it uses
only one z-index per element. This means, the author has to separate
problematic paths in a group of paths and has to determine which path
is on top at which time. In this case the intellectual challenge is left to 
authors, not to the simple viewer. For me this sounds more promising
to be realised - but of course, if there is a simple method for viewers,
this would be much more convenient for authors ;o)


Olaf

Received on Tuesday, 26 October 2010 10:01:43 UTC