Standard version: 1.5

Major Change

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

(Bruno said:)
 
Cool,


we have stopped banging our heads together on this one then

 

b

 

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

 

Pierre

 

Bruno Nicoletti wrote:

 

Hi Pierre,

 

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

specific UI

- callbacks to the effect stating when things have been

added/clobbered

- 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

groups (?)

- suite to all plugin to add/delete members of variable length

params

 

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.

 

b

 

On 24 Jun 2006, at 01:41, Pierre Jasmin wrote:

 

Bruno Nicoletti wrote:

 

Hi All,

 

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

addShapeParams

endShapeEdit // switch to the "arrow" mode

deleteShape

showShape, hideShape

getShape // some attributes like opened/closed and the set of

points

getShapeParam // then use the standard param call but shape num

must

be passed

getNumShapes

getVertex

setVertex

deleteVertex

insertVertex

 

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

 

Pierre

 

 

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

should go.

 

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

rotomask vertex.

 

paramSuite->paramDefine(paramSet, kOfxParamTypeRoto, "myRoto",

&propHandle);

 

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

 

OfxRotoHandle rotoValue;

paramSuite->paramGetValue(rotoParamHandle, &rotoValue);

//// do stuff

rotoSuite->rotoRelease(rotoValue); // done with it

 

or to set a value

 

OfxRotoHandle rotoValue;

rotoSuite->rotoInitialise(&rotoValue);

/// do stuff

paramSuite->paramSetValue(rotoParamHandle, rotoValue);

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

(yukky)?

 

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

vertices etc...