|
|
Interaction Editing- Copy/Paste/Duplicate in Viewer.... and that says it all ;-) Copying/paste/delete/duplicate, etc, actions on items in the Viewer get pushed to what's going on in the Editor. This is pretty darn standard in many graphics engines. Too ambitious for a plugin?
|
Sizing and rotate, as well...
You talking about updating input ports or manufacturing new patches in the Editor from interaction with the Viewer Window?
Sorry I don't quite get it but it sounds a) ambitious and b) very interesting
Both.
Hmm, maybe to get it, look at something like this:
http://www.youtube.com/watch?v=dm5vEzzv1wY&feature=related
...and note how duplication, scaling, transformation, etc., is all happening via interacting with the visual representation of the graphic.
Oh man you're c) very ambitious.
This stuff is a different ball park not sure how they would go about welding that paradigm to the QC-graph paradigm (which is sort fundemental to QC at present!).
Imagine being about to execute QC patches inside JS
like he is.
Not sure how/why I'd want to use it yet though…
I thought you would find the javascript methods interesting, even though that wasn't my main thrust.
I see something like this as what amounts to an interface, other app that is working as part of QC (like the composition a/b thing) or Kinemecore, or something like the current Interaction that is going on in the Viewer, but more useful, and maybe some patches that are specifically geared towards interaction editing (like a subset of filters that you manipulate through interaction in the Viewer or some sort of preview).
So, if you had a cube in your Viewer, you could literally highlight it, copy and drop the duplicate where you want it to be, and while you're doing this the Cube would duplicate in editor and get populated with the values. So there is precedence for a little sliver of this, just not things like duplication, deletion, etc.
If you saw how the Interaction mode on the Editor works in SL, you will see that what happens is that it works for x/y placement, and it does push those values to the correct input ports on the renderers on the Editor surface.
The thing is, that I believe that this kind of Interaction editing mode has to NOT ALLOW CI OR MAYBE EVEN TEXTURING. This is the only way that I think that editing in this manner would be accurate and reliable.
It should simply be a quick and dirty representation of where the objects really are in a given macro, so that it isn't affected by any kind of CI that is being applied in RII scenarios. Ideally, it would be much like "extra editor", but a kind of interaction editor/viewer that opens for a given consumer macro.
The fact that Interaction editing happens in the same Viewer as the main feed is a big problem with Interaction editing in the Viewer. Interaction editing/setup in the Viewer should really be happening in it's "own" Viewer world. If this was adapted, then the lackluster approach to Z placement would naturally be mitigated, because one could turn a scene in the Interaction Placement Viewer, and move it in Z by pulling it back in forth in what appears to be X, with the scene being viewed in profile.