Bezier Splines

Here’s a list of things about inclusion of Bezier splines into FF that seem obvious to me. All these things can be implemented in Filter Forge without much problems:

1. We’ll need a separate type of components and inputs for Bezier splines (with pink as the official component color?). See an example pic below.

2. We’ll need a lot of spline-to-spline components. Here’s my current list: Creation: Circle / Ellipse, Elliptic Arc, Line, Rectangle, Polygon. Modification: Outline, Affine Transform, Perspective Transform, Boolean Ops, Tesselate. Editing: Append Segment, Append Linear Segment, Append Arc, Insert Point, Break At Point, Close, Merge.

3. A spline is just a spline, it’s a data structure, not a drawable object yet. Therefore, we’ll need components that ‘draw’ splines, that is, convert spline connection type to map/green. Examples may include simple fill, or a distance transform where a Map component outputs distance to the nearest point on a spline (see the pic below).

4. (Some more notes on the Distance Transform component: it’s a Map component (with a Spline input) that outputs distance to the closest point of the nearest shape, perhaps even according to customizable distance functions / metrics, such as Manhattan etc. The distance could be returned by the component as a HDR grayscale value, with positive channel values for points inside closed shapes and negative values for points outside closed shapes. The main benefit of this distance-returning component would be the ability to create perfect, non-pixelated outlines and bevels that play nice with Filter Forge surface rendering and HDRI lighting.)

5. Unlike map components which are defined implicitly, by a function, splines are are represented explicitly by a list of points, not by a function that returns values when called. Which means that spline components should (must?) be evaluated at prepare-time (as opposed to sample-time) -- that is, all spline components must be evaluated (and must have their results explicitly stored in memory) before sampling begins. This means that spline components cannot have map / green inputs, which, in turn, means that they cannot participate in sample-time green Loops. On the other hand, we can implement a Spline-typed Loop (Sigh. I wish Filter Forge had proper Haskell-like polymorphism so that we didn’t need to duplicate the Loop functionality for every new type that comes across.)

6. Since splines are defined explicitly, not implicitly, we can’t have endless fields of splines similarly to what we have with, say, noise functions. Therefore, splines in FF will resemble its Free Ellipse / Free Polygon components where we have a single non-repeating shape floating in the middle of an endless black cosmos. Which, in turn, may mean that using splines in a filter will disable seamless tiling.

So, how would YOU integrate Bezier splines into Filter Forge, considering my points above?

What operations / functionality would be necessary for you and what would be nice to have? Will my list of Obvious Things list be enough for you? What supporting machinery would be necessary (I mean numeric math, loops / iterations, point type etc.)? How would you deal with seamless tiling? How would you deal with import / export of splines? What kinds of stuff would you do with bezier splines?

Let me know your ideas!

Question regarding Explicit Vs. Implicit Control:

What will be the extent of explicit control over splines? Is there a point in the filter tree where we go from explicit control to implicit control of splines, or will the whole vector sub-tree be explicitly controllable?

In your example image, the user explicitly defines points, but once the initial spline data structure has been created in the Ellipse and Rectangle components, it is then modified implicitly via the Boolean and Outline components.

Let's say I like the result of the Outline component, but I'd like to modify some point positions and spline tangents. Will those kind of explicit edits be possible anywhere in the vector sub-tree?

Furthermore, if I changed the Boolean operation from Union to Intersection, any explicit edits after Boolean would be invalid, since my data set of incoming spline points will have completely changed. This sort of violates the principle of procedurality that permeates FF, and begs the question: How far should explicit control really go?

uhm... could we define some of these terms, please?

Quote
Vladimir Golovin wrote: Do we need additional control components, for example XY Point?

This would definitely be nice, even if vector components never make it into FF. What's the current status of 'multiple-output components'?

Quote
Here's how it may look:

Distance Transform and Splines! OMG!

These have been helpful:

http://members.shaw.ca/spvincent/plug...rvius.html

https://reference.wolfram.com/language...Knots.html

https://reference.wolfram.com/language...ights.html

https://reference.wolfram.com/language...egree.html

Adding math functions to create lists would be swell: https://www.youtube.com/watch?v=mxBUrIxwzHA

EDIT: Oh, and the ability to tween between 2 shapes: http://vvvv.org/documentation/damper-(animation)

Quote
Let's say I like the result of the Outline component, but I'd like to modify some point positions and spline tangents. Will those kind of explicit edits be possible anywhere in the vector sub-tree?

Ideally, yes, you should be able to directly access and modify points at any stage. Below is a raw list of operations on splines that I consider to be a reasonable toolset for procedurally creating them. I wrote this list for another project (see the new thread on it soon), so it may not be directly applicable to FF (due to its lack of Turing-completeness in its nodal language):

Creation
SplineFromPointList
Circle / Ellipse
Elliptic Arc
Line
Rectangle
NGon / Star
Spiral

Creation From Other Splines
Combine // NOT Boolean
Boolean Ops (And, Diff, Union, Xor)
Blend (from two splines and a percentage)

Modification
Outline
Affine Transform (Move, Rotate, Scale, Skew, Flip)
Tesselate
Perspective Transform?
SmoothPolygon (a-la Subdivision)
Optimize / Simplify

Editing
Append Segment ( BezierPoint, CloseFlag )
Append Linear Segment
Append Arc
Insert Point (at point, at t, at distance etc )
Remove Point(s)
Delete Point(s)
Break At Point / Open
Close

Query
Is Open / Is Closed
Get Point At T
Get Closest Point
Tangent at Point (for arrows etc).

Quote
Furthermore, if I changed the Boolean operation from Union to Intersection, any explicit edits after Boolean would be invalid, since my data set of incoming spline points will have completely changed. This sort of violates the principle of procedurality that permeates FF, and begs the question: How far should explicit control really go?

Ah, the good old topology dependence problem, as they call it in 3DS Max.

I tried to introduce the concept of point selection and operations on said selected points to combat this. 3DS Max does exactly the same: you can apply modifiers to a selected set of vertices / faces / subobjects selected by a previous modifier in the stack.

(Then I learned a bit of Houdini and it demolished my entire concept of selection, which began to seem extremely limited in comparison with Houdini's attachable key-value data.)

So I abandoned this approach and went with another one. See the examples of the new nodal language in the nearby thread on the Next Big Thing.

I'm still not sure which one is better.

Quote
Vladimir Golovin wrote: Sphinx, the problem with converters to Gray is that everything Gray is evaluated on the Prepare stage, that is before the rest. For example, a Green-to-Gray converter is currently impossible because this means sampling a Green component during a Prepare phase, which must be completed before any sampling can begin.

It may be impractical within the current design, but I fail to believe it is impossible: I can create a new 1x1 image and take that value and enter into a gray input in a secondary rendering "pass" with the complete filter.

Just think about that green -> gray converter as a single sample rasterizer that need to render its sub branch before the main rendering can take place

In the context of Filter Forge I wouldn't expect it to be nearly as intricate.

I would expect to be able to draw a spline with a Spline Input Component in similar fashion as you can currently draw a curve with the curve control component and then plug it into a Spline Draw Component to create a fill and a stroke, perhaps a gradient fill. The Spline Input Component would be accessible at the Settings level, not only at the Editor level, and you should be able to copy and paste the spline information from one filter to another.

I would expect to be able to import a spline saved in some common vector format into the Spline Input Component.

Having duplicates to existing components (ellipses, rectangles, stars etc.) in spline format would not be a vital necessity for me.

The ability to choose the boolean state of the individual subobjects within the Spline Input Component and group splines for further boolean operations would obviate a lot of the other needs.

Using Shift for constraining to vertical, horizontal and 45 degree angles would also be important.

This way just two components would cover just about all my bezier spline needs for Filter Forge. The Spline Input Component would have some internal complexity, but it wouldn't complicate the overall program needlessly.

For a whole new program, my answer would likely be very different.

Quote
Vladimir Golovin wrote: Dilla, what you described above is best implemented via domain repetition. [...] endless spline field will be represented as a regular map (green) component

Yes, domain repetition. Exactly what I meant. A must-have to make vectors useful for texturing work, IMHO.

Quote
Vladimir Golovin wrote: Ah, the good old topology dependence problem, as they call it in 3DS Max. [...] (Then I learned a bit of Houdini and it demolished my entire concept of selection, which began to seem extremely limited in comparison with Houdini's attachable key-value data.)

I started to look into Houdini years ago, but got turned off rather quickly as it appeared to be aimed at TDs exclusively. Disclaimer: I'm not a programmer.

Could you maybe summarize how Houdini achieves this independence from selections/topology? I'd be really interested to hear how they circumvented that problem.

Quote
Vladimir Golovin wrote: Ideally, yes, you should be able to directly access and modify points at any stage.

I like that idea. Obviously, to really keep it procedural (and in the spirit of FF), you'd have to have a way to circumvent that selection/topology-problem that was mentioned.

Quote
One useful way to 'draw' a spline would be to map/repeat a tiling texture along its trajectory. This way you could make a bark texture follow a branch, make text follow a path, make stitching follow the edge of a piece of cloth, etc.

Good idea, especially if there's also a way to control the contour thickness along the spline (via a curve component for example).

A 1500 point fine spline FWIW:

My purpose is to show that splines can be a useful way to get the look of tens of thousands of points. Like your 'Atomic Particles' video, but with symmetric parametric equations and fewer particles perhaps. An elegant de jong attractor at significant cost savings.

That is Skybase's colored image I referenced. The image was linked from image search. Here's the link to the video: https://www.youtube.com/watch?v=Iq54fFsEW2Q

The black and white image was done with a custom Mathematica program.