- From: Luke via GitHub <sysbot+gh@w3.org>
- Date: Thu, 08 Sep 2016 17:42:07 +0000
- To: public-svg-issues@w3.org
Hey guys, apologies for the delay - I've been playing around with a
few concepts amongst other projects too; the above comments are
awesome! I'm really looking forward to seeing where SVG is taken in
the future. @AmeliaBR Yep I've used SVG filters but they are very
limited in comparison to what filter forge (and similar) can create,
and I also agree that from an author point of view it's quite
difficult to use in its current form. I.e. wood starts looking more
like this:
The major node categories are ~16 noise options, gradients, graphs
(very useful for "tone mapping"), mathematical operators and
repetition. SVG does kind-of cover these categories, but it's the
current lack of diversity in those noise functions that seems to stick
out the most.
As far as usability is concerned, I would imagine the major issue is
that SVG filters represent a graph with a much more complex flow
instead of the very familiar tree like everything else in SVG. I.e. a
path adds to whatever is before it; a blend does not. So maybe it
would help to represent the graph of nodes as a tree as much as
possible; that would somewhat bring it into alignment with the rest of
SVG. Based on the above stacking approach, that also makes
implementation simpler too. There's an interesting range of options
here:
```
<filter id='Wood'>
<noise type="perlin" baseFrequency="0.3 0.1" numOctaves="4"/>
<!-- Perlin noise is now on 'this' stack -->
<blend operator="add" in2="anotherFilterID"/>
<!-- Here we've now got noise + whatever anotherFilterID outputs
-->
<toneMap graph="graphID"/>
<!-- It's now been tonemapped -->
</filter>
```
To me, the above is nice and easy to follow through. A nice bonus is
ordinary SVG nodes can be used too - i.e. dropping in a path node
would be understandable. It still uses some ID references, but the
flow is much more well-defined. To avoid ID references entirely, it
could make use of nesting inputs, essentially flipping the flow in
reverse:
```
<!-- The filter node represents the one and only output, so start from
that and work downwards -->
<filter id='Wood'>
<toneMap>
<graph>
<!-- An inline tone mapping graph -->
</graph>
<blend operator="add">
<!-- Adding noise to some other noise -->
<noise type="perlin" baseFrequency="0.3 0.1"
numOctaves="4"/>
<noise type="voronoi" function="manhatten"
baseFrequency="0.3"/>
</blend>
</toneMap>
</filter>
```
Lots of interesting combinations available with the above. I like this
form, but something feels slightly "off" that it's flow is upside
down in comparison to the rest of SVG. For example, introducing
multiple path nodes into the mix would therefore be a very odd
experience indeed:
```
<filter id='Wood'>
<path d=".."/>
<!-- Who renders first..? -->
<path d=".."/>
</filter>
```
However, at least it _has_ a flow, and it can easily represent any
number inputs to each node.
Flipping back to the second part of this, triangle meshes, I can see a
lot more advantages now if the gradient meshes can be GPU
accelerated. I think it would still be quite convenient to introduce
raw triangle meshes, possibly defined in the COLLADA format for easy
compatibility, as it potentially allows for a polyfill option when
introducing new features (i.e. if triangle meshes were available in an
earlier iteration of SVG, a JS library could potentially polyfill
gradient meshes by triangulating them and dropping the resulting
triangles into the SVG's document).
--
GitHub Notification of comment by Bablakeluke
Please view or discuss this issue at
https://github.com/w3c/svgwg/issues/257#issuecomment-245678506 using
your GitHub account
Received on Thursday, 8 September 2016 17:42:13 UTC