Standard version: 1.5
I think RE:Vision and Foundry via API email thread had a reasonable compromise. Paste in our discussion as reference. Imagineer has offered interest in such suite. This is an old discussion at this point, might have changed my mind and some of the supporting visuals are gone. I repaste anyway as reference. (Sorry for formatting)
Essentially we need a single shape parameter and a dynamic list one (with parameters per shape).
we have stopped banging our heads together on this one then
On 28 Jun 2006, at 23:04, Pierre Jasmin wrote:
It could be as I think you suggest: a param array container [item
1,2,3...] and a single spline param
I could intoxicate the list with tons of details, in the end it only
matters if one host wants to do it
This generates a tons of notifies and however it is it would need
to be patched with the engineers of the product anyway
Bruno Nicoletti wrote:
I am interested in a single roto spline per named roto param, which I
can access and change the points on. The UI is totally up to the
host, I just want to be able to say 'give me the roto named "fred"'
and do what I need to do.
You are after something more complex than that, having a variable
number of rotos + a set of params associated with each roto. This
sort of comes back to the discussion we had before, about a params
being able to vary in number via the API. We could attempt to do
that , but it means revving the param suite.
Would something like this work for you....
- being able to specify params as being variable in number, in
effect such params can be a variable length array of values, so
rather than getting param 'fred' you need to param 'fred[i]'
- the user gets to 'add/delete' these via some host
- callbacks to the effect stating when things have been
- if a group param is variable in number, then all the groups
members are variable in length, but manipulated and logically
grouped together on the interface,
- adding deleting works on the group as a whole,
- you can't have variable length params inside variable length
- suite to all plugin to add/delete members of variable length
Plug-ins and hosts flag whether that need/support this kind of
behaviour, allowing fallbacks behaviour on those that don't.
Pete and Pierre, if we then have a roto param, which represents a
single shape (as in my suggestion), and allow that to be of variable
size (so you can ask for the ith roto named 'fred'), along with the
above behaviour, would that work for you? As you could make variable
length groups that contain a roto + whatever else you need.
Host folks, how hard would any of the above be?
Finally, Pierre, could you describe in more detail the functionality
you want from each of the functions you mention below? I'm not quite
sure what they all do.
On 24 Jun 2006, at 01:41, Pierre Jasmin wrote:
Bruno Nicoletti wrote:
re-opening a can of worms. I'd like to define a roto param,
which is closed or open bezier curve which is defined along the same
lines as all the other params.
Bruno, I am not quite sure what this parameter you describe
defines-collects: a set of splines (a container with a list of
rotosplines) or a one spline - one parameter mapping, or something
that defines an input outside the editing scope of the effect?
What I am interested in is something that in the end is a suite of a
dozen+callbacks. That suite would look like the list that
follows, and Bezier only is fine. [in my own language that would be a checklist parameter which is of type rotobezier]
Actually if there is an host interested, I am not sure when but we
probably could beta-develop-test such Roto Suite in ofx context
given that we understand I think a lot of the gotchas at this point
(supporting collecting similar data from 6 apps right now, where
one is ourselves (in discreet systems where the main problem is cannot
declare enough parameters) and another one (in xsi) where we are not
embedded but "connected" via a scripted operator which is a complete kludge to pipe curves data although if you use your effect as what you put as the camera rotoplane background you eventually get a visual
feedback). The others we support like that now (with their own personality, Shake, Fusion, Combustion and AE) allow us to more or less do what ends up being something like this.
createShape // eg: this is a callback, for example in
Combustion we use that to assign our spline coloring scheme
endShapeEdit // switch to the "arrow" mode
getShape // some attributes like opened/closed and the set of
getShapeParam // then use the standard param call but shape num
This is separate then roto for generating a matte sort of thing,
Which could be if one is interested something that "super-suites" this. So
there is no concept of fill, linewidth and fill modes and feathering and what not. This is simply a Bezier shape editor abstraction
(including support for single points). This is also separate from the issue of making your own bezier curve editor (which then would imply concept
such as collecting display viewport, events, overlay drawing...).
Here's some real world visuals outside of OFX context ( The image
is a few thousand pixels wide)
On the right (Fusion 5), you see the box below Add and Delete
(This is standard sort of checklist container model in Fusion 5 SDK, "Add" an item in the checklist is part of the host SDK, it you apply their
Tracker you will see the same Add and Delete and checklist box etc).
User press Add to add a spline. Note there is the spline control-
Editing icons in the viewer (much like Shake when you embed a roto but more elaborate) AND below the spline checklist selection box there are some parameters, these are per spline parameters, so when a user selects a different spline we can change the displayed parameter content to reflect the values associated to that spline (for example the "Use"
animated boolean -- that's plugin defined. In the case of warping
etc which require shape pairing, we are able to detect an insert or
delete point event in a shape and apply it to the other shape... so manage
all this by ourselves. Note it does not have to "look" like that, in the
left i n image in Combustion it shows up in the Timeline as per
shape twirlies, that's just the host presenting data the way it wants to users.
That's somehow how it should work I think. This statement has two
meanings: 1) it's how it should work for rotosplines AND 2) it's a
method of doing that could be abstracted to support other data
types.(Bruno, wouldn't that be a good way to contain a bunch of trackers?)
// Some parameter arithmetics for who does not realize how many
parameters we are talking about
One reason to rely on host is basic elegance. When you start to work
with 20 splines with a bunch of controls etc... it quickly becomes a
mess of parameters so the host is in a better place to know where it
Using the Combustion Per Spline as an illustration example:
Per rotoshape: 6 plugin defined params, a transform with 7 values +
group title, and 6 values inside of each point + group title
So let's say you have 10 embedded shapes with 10 points per shape
That's 6+8+(10x7) = 84 params per shape X 10 shapes + 10 shapes
group = 850 params for the embedded roto part of the plugin for only 10
Shapes if I was to drop this as regular control params (and do it
myself) --and it's a typical problem for hosts so I imagine they have their own way of handling that so it's navigatable as well and I want to be as much as the host as can be for this sort of things. Another
reason for that (although not universally expected to be true) is cut and paste,inheriting of host service such as bake or link a point to a
paramSuite->paramDefine(paramSet, kOfxParamTypeRoto, "myRoto",
A separate suite would be needed to ask about the roto (number of
points, open/closed, get/set points) via a blind OfxRotoHandle.
Values would be fetched and set as per other params...
//// do stuff
rotoSuite->rotoRelease(rotoValue); // done with it
or to set a value
/// do stuff
rotoSuite->rotoRelease(rotoValue); // done with it
OFX host folks, how hard for you?
Also, do your rotos allow the number of points to vary over time
some hosts in the universe do, because of that we have to support a
checkbox that says "match vertices [x]"
we also assume that when you insert a point on a shape. it's
added tothe whole sequence at the same relative position between two
No comments on this change yet