Re: What do you want out of a path API?
Re: What do you want out of a path API?
- Subject: Re: What do you want out of a path API?
- From: Peter Litwinowicz <email@hidden>
- Date: Fri, 10 Sep 2010 11:56:00 -0700
- Thread-topic: What do you want out of a path API?
Title: Re: What do you want out of a path API?
> Do you find it helpful for us to also provide a method for evaluating points
> in parameter space? It seemed like output space was the hard case, so I was
> thinking we'd add that, but in the parameter space is pretty easy, so we'd let
> developers write that themselves. But we could add both.
It would be helpful to have both. Yes. That way people don’t need to recreate the math.
>> Oh, that is useful. Why leave it out? :-) It's just a call to implement
>> and query the status of the mask, right?
>
> Yeah, it's very simple. I was just questioning whether it was useful. But if
> it is, no problem!
> Can you elaborate on this? When you say "attach our own parameters to each
> spline," do you mean that you have some fixed set of parameters, and you need
> a copy of those parameter for every spline attached to the image (or plugin)?
Yes. Attached to the plugin (not image, because what if I have two instances of the same plugin, using splines? How do I differentiate which params go with which spline for which instance of the plugin?)
> For example, you want a checkbox, a slider, and a color well. And for each
> spline created, you need those same 3 parameters in 1 plugin? Is that right?
I need a separate instance of those 3 parameters for each spline for the plugin.
For example, if I have 3 splines that my plugin is using, and
>
>> As far as UI goes, I also believe that you should attach splines to the
>> individual plugin instances, so there is no doubt as to "who" owns the
>> plugin (the masking interface of Motion, the plugin, which plugin, etc.) .
>> The After Effects UI model is all wrong. You should really look at the
>> Combustion model for the UI (Ummm, Guido should be able to help you there
>> :-))
>
> Hmm.... I will definitely ask Guido about it. It's unlikely we'll be able to
> change the model of what masks are attached to, but I'll give it some thought
> and talk to both our UI people and our spline people and see what can be done.
> (But don't get your hopes up on this one. ;-) )
If you don’t do it like I suggest, then when you list the spline’s per-plugin per-spline params, and you have more than one pluging that uses splines, how do you know which spline-param goes with which plugin? It gets very messy from a navigation and UI perspective.
I’m not trying to make the problem bigger so that you don’t do it, but you need to experience what per-spline params in an app is like, and I suggest going back to Combustion to see what they did there, where they got it correct.
Here is a picture: each spline is listed as attached to a particular plugin instance, and with each spline is a set of per-spline parameters (Geometric “Points” added by combusion, and are the control points for the spline):
> It would be helpful if we could copy and create a duplicate of a spline, so
> that when the user creates a source or dest spline, that we can
> automatically create the other one. It would be useful to programmatically
> copy keyframes from one spline to another (for similar reasons). It would
> also be useful to delete vertices internally and add vertices
> programmatically. So that if one spline of a pair has a vertex added by the
> user that we can add a vertex in the corresponding place on the other spline
> automatically (by us internally).
This one sounds tough.
No worries, we can live without this one.
But once you start adding and removing vertices, do you need to also set keyframes on those vertices programmatically?
Of course! We would want to do things like “duplicate src spline to dest spline”, etc. and that might mean at a particular point in time, or over all keyframes, etc. We can live without this option, but it is really useful!
Another way to deal with this is to have the option make a spline primitive really be a pair (also useful for feathered edge masking too! RE: Shake).
Pete
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Pro-apps-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden