Relative vertex key enhancements.

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Dec 30, 2004 4:19 pm

Ghost Warrior
http://kazeghostwarrior.com/FA/FA.htm

Another example of the clutter method.
With visual 4 points slider for realtime record, a bit like broken one.

The rest seems like it could use improvement.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Thu Dec 30, 2004 5:19 pm

broken wrote:From all of this, it looks like what we need as the first fundamental step is to redo the RVK system so it uses one curve per RVK/blend shape, representing the percentage of influence.
Hmm, isn't it already like this? In the IPO/Mesh window it displays one curve per RVK. The interface is still horrible though...
broken wrote: From this, it would be a good base to build other things upon in a flexible way, like combining them into Actions (if we get the ability to use a collection of any Ipos as an Action), or sliders, or etc.
Definitely! If we get the ability to map any keyable parameter to a slider and have driven keys, the possibilities for setting up super-cool facial and body rigs seem almost endless.

For example you could use the driven keys to combine both a morphing (RVK) with bone movement to create complex muscle stuff.


Joeri: I can't quite work out your mockup. How does one set up driven keys in your proposed system? I can't see where and how you link parameters... Would you care to elaborate your thoughts?

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Thu Dec 30, 2004 10:16 pm

Image

The driven keys could be easy.
But with IPO changes I'm not sure how compatible it will stay.
Forget about the slider, that's to make things more complicated.

Select the 'tanden' and then the 'Wheel', the wheel is active and will be the driver. The tanden will be driven.
Press I for IPOmenu (i guess).
Select DrivenKeys from menu
Now a new IPO type is made, Driven. In the IPO window we see the driver on the left and the driven on the right. (Maybe there are more driven, then the "Tanden" near the slider should be a popup.)
Select a channel on the left: Maybe RotZ (horizontal legenda turns into degrees), and select a channel on the right LocX (vertical are blender units).
Now draw a curve CTRL-LMB 0->0, 100->10. This means when the wheel is at 0 degree the Tanden will be on blender unit 0,y,z.
Rotate the wheel, at any speed (give it it's own IPO if you want), and the Tanden will stick to the wheel. 50 degree will put the Tanden on 5,0,0.

Now what about the slider?
Okay, hmm,... I don't know. :)
I like the RGB sliders in the material. You slide them and the colors change. Make an animation and press alt-A in the material window: look at them go! Just like an audio mix panel.

This slider should be the same I think.
It's represents the red curve on current 'frame' (being the wheel rotated at 100 degree in this example). So I can pull the slider instead of the curve vertex. The button on the left allows me to set a keyframe. And/or have autokey: moving the slider sets a key.

But then blender physics come in,... If we want another wheel channel linked to another Tanden channel, do we put it in this Driven datablock, or (as broken suggests) do we keep 1 curve in 1 IPO. (And have a smart way to draw more curves in the same display, I rather like this idea, this could mean different legenda's [scales] for different channels and thus no longer location vs rotation scale problems)

With the object buttons I'm experimenting with what type of channels are represented in the display, and can be used as input and output for the slider. If we say the curve contols the slider then the output could be redirected to anything. Or rather any channel.
That's what this image tries todo:
It's a 'normal' curve as input (IPO on left of slider).And Material channels as output
Image

But the input could also be a little python:
Image

So basicly it's no longer the IPO that is the animation controller, but it's the slider. The list of sliders needs to be evaluated per frame. They can have a curve as input or python or a data block channel. And have all kinds of outputs, object channels, material channels, maybe even other sliders.

I hope this makes my thoughts a little more clear.

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Fri Dec 31, 2004 1:56 am

Monkeyboi wrote:
broken wrote:From all of this, it looks like what we need as the first fundamental step is to redo the RVK system so it uses one curve per RVK/blend shape, representing the percentage of influence.
Hmm, isn't it already like this? In the IPO/Mesh window it displays one curve per RVK. The interface is still horrible though...
No, I mean one curve per shape. Right now we have 1 curve per 'sequence of shapes' - the one curve controls the amount of blending between all the different RVKs. What we should have is 1 separate curve for each shape, controlling that shape's influence. So if we have 5 different blend shapes, we have 5 curves we can edit in the Ipo window at the same time.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Fri Dec 31, 2004 3:43 am

broken wrote:No, I mean one curve per shape. Right now we have 1 curve per 'sequence of shapes' - the one curve controls the amount of blending between all the different RVKs. What we should have is 1 separate curve for each shape, controlling that shape's influence. So if we have 5 different blend shapes, we have 5 curves we can edit in the Ipo window at the same time.
I still disagree, there IS one curve per shape. Remember shape=RVK. And remember to use RVKs and not AVKs (Absolute Vertex Keys) which are pretty useless.

This is a screenshot from Blender:
Image

The orange IPO curve controls the ammount of 'happyness', while the red IPO curve controls the 'mouth openness'. 2 shapes = 2 curves..

Anyway, that's certinately not saying the RVKs couldn't do with improving.

Like, for example the name. 'Vertex key' is very confusing because it sounds like it is stuck to a specific keyframe. An RVK is merely a second iteration of a mesh that can contain alternate positioning of vertices. These iterations can then be blended and added to each other to create a wide range of shapes.
'Morph Target', 'Blend Shape' etc. is much more appropriate for what it is.

The main problems with Blenders RVKs are IMO:

-sliders are oddly places in action window, even though RVKs cannot be included in actions.
-creation and management of RVKs happen in the strangest 'blue line' interface inside the IPO window under Mesh. Each line represents an RVK/shape. This is not in any way consistent or apparent how to use, plus it is not clear and it's hard to see what's what.
-there is a low limit to the amount of RVKs one can add (64). Gollums facial expressions (not counting mouth phonemes or body muscles) count 80.
-there is a disability to combine RVKs with actions or bone movement (Driven keys could resolve this)
-disability to manipulate all RVKs/shapes at once (to make a change across all the instances if the mesh)

And then there is a lot of fancy stuff that could be added such as Brokens nifty idea of having triangles etc. to represent percentage between RVKs.
[/img]

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Fri Dec 31, 2004 4:38 am

Monkeyboi wrote:I still disagree, there IS one curve per shape. Remember shape=RVK. And remember to use RVKs and not AVKs (Absolute Vertex Keys) which are pretty useless.

The orange IPO curve controls the ammount of 'happyness', while the red IPO curve controls the 'mouth openness'. 2 shapes = 2 curves..
Ah yes you're right. I am getting mixed up with absolute keys, which is what I used most recently. The whole crazy lines interface confuses me a lot, since the position of the horizontal lines also influences relative keys as well as absolute keys. But I guess what I really mean is that each RVK should have a separate Ipo, not a separate curve, just like the transformation of a bone has its own Ipo. Then these Ipos could be either collected into actions, or used to drive other things.

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Fri Dec 31, 2004 12:50 pm

I do like the idea of all channels of an object being in 1 IPO datablock.
Otherwise we would need 6 IPO objects to move and rotate an object.
Before you know it you'll get IPO grouping feature requests.
But yes, it seems all the curves are incompatible; you can't connect a R to a LocX. That would be much easier if all curves would be in a 0.0-1.0 space.
Maybe grouping is the solution. Have an IPO per channel (with or without slider) and design a new grouping window where the channelIPO's can be displayed together. Let the user name them. "CarRide" IPO group could hold channelIPO's LocX, LocZ & RotY. Some new names might come in handy as well.
The IPO's could be in a 0.0 - 1.0 x 0.0 - 1.0 space with a mapping.
(-1.0 and 2.0 are allowed, just not default).
horizontal mapping would be time by default and vertical mapping depends on channel.

Sounds like a good idea to me. :)

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Sat Jan 01, 2005 5:29 pm

broken wrote:I guess what I really mean is that each RVK should have a separate Ipo, not a separate curve, just like the transformation of a bone has its own Ipo. Then these Ipos could be either collected into actions, or used to drive other things.
The reason why bones have their own Ipo datablocks, is that each bone has several animatable parameters, such as rotation, scale and movement. Since each RVK only has one parameter, influence, it would be pretty silly IMO to have an IPO datablock per RVK. I agree that the ability to mix IPOs is crucial, but this could just as well be achieved if you could key all the RVKs together in IPO chunks. These chunks could then, as with all other IPOs, be blended and modified in the NLA, and with driven keys, each curve could independently be assigned to other parameters.

This is assuming the the ability to mix IPOs in the NLA gets added, and that we get driven keys, ofcourse.
Last edited by Monkeyboi on Sun Jan 02, 2005 2:47 am, edited 2 times in total.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Sat Jan 01, 2005 6:09 pm

For a replacement to the RVK system, I propose the following:

Blend Shapes.

A new name is actually fairly important IMO, 'RVK' is not only unclear, it's misleading. We are not dealing with a 'key' as in 'keyframe', we are dealing with a shape.

Anyway, the concept of the Blend Shapes is exactly the same as RVKs, in that you have a mesh with several iterations of itself with different vertex positions stored. These iterations, or 'shapes', can then be added to each other, so that the blinking of an eye doesn't overwrite snarling on the mouth, again just like the RVKs can do now. And similarily, the influence of the shapes can be varied and animated over time.

The difference is mainly to do with the interface. We know the odd 'blue line' interface where you deal with RVKs now. Let's analyse it's problems:
  • * You currently add new RVK just as you add a keyframe using the I key function. This is confusing because you are not adding a keyframe, but a new shape. This shapes influence can then later be keyframed, but that is a different matter.
  • *Sliders are only accesible in the Action window, even though RVKs cannot be included in actions, and has nothing to do with the Action window.
  • *The 'blue line' interface is not consistent with anything within Blender, and doesn't lend itself well to user - ie. not intuitive. Plus, you cannot clearly see what blue line represents what RVK.
  • *There is a hardcoded limit to the amount of RVKs one can add.

This I have thought of how to solve in a number of ways, but in the end I came up with a system that mirrors the way you create constraints. This would reside somewhere inside the Editing context.

Image

The nice thing about this system is that it allows you to quickly start using it, because it is reminiscent of adding constraints. It is a centralisation of what used to a chaotic system spread all over the place with creation, management, slider editing all happening in different windows. Having it centralised is much neater, and it makes it easier to pick up and use.

So in this panel you have all the features of the old 'blue line' interface + sliders + a few new things.

The blue lines enabled you to visualise a shape after you had edited it, by clicking on the corresponding line. This can now be done using the 'Display' button. In order to change the shape of an RVK, you used to select a blue line, then go into edit mode to change that shape. With this system, you'd simply press 'Edit Mesh Shape'. The old slider options, where you also renamed RVKs, was quite hidden - strangely, you had to click on the text label of the RVK in the action window. This is now simply displayed in the Blend Shape box.

The new features are the ability to edit all shapes at once, the ability to set an IPO curve color, and to let it display blend shapes in the 3D window.

Below are further explanations of the button functions:

Image

Here is a shot of how the blend shapes look collapsed. As you can see, they are very compact and simple.

Image

Ofcourse, details like exactly how the 'Slider in 3D View' function will work can be discussed as a separate project. It seems as though Broken has some interesting idea for concepts on how to do sliders.

-W

matt_e
Posts: 410
Joined: Mon Oct 14, 2002 4:32 am
Location: Sydney, Australia
Contact:

Post by matt_e » Sun Jan 02, 2005 1:35 am

Monkeyboi wrote:The reason why bones have their own Ipo datablocks, is that each bone has several animatable parameters, such as rotation, scale and movement. It also means you can share Since each RVK only has one parameter, influence, it would be pretty silly IMO to have an IPO datablock per RVK.
Ok, I tend to agree now :) Though like you say, all of this discussion is quite hypothetical - dependent on what sort of functionality we can get to mix and match and connect them.

Your following post looks very very interesting, nice, simple, centralised and consistent. Once crit I'd have with the proposal though, is that it doesn't look easy to tell which blend shape you're actually editing after you've pressed 'Edit' or 'Display'.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Sun Jan 02, 2005 2:24 am

Broken wrote:Once crit I'd have with the proposal though, is that it doesn't look easy to tell which blend shape you're actually editing after you've pressed 'Edit' or 'Display'.
Quite true. Would it be out of the question to add a little label in the 3D View? So when you click the button to edit the 'Smile' shape, it says 'Smile' in the bottom corner of the 3D View.

Or maybe even better, there could be a dropdown menu in the header next to the modes dropdown (only there in Edit mode) that would let you quickly jump from one shape to another, as well as serve as a quick way to check what shape you are actually editing.

Like so:
Image

Here's the menu unfolded. I imagine you should be able to chose 'Base shape' which is the basic shape of the object, as well as the aforementioned 'all' mode, that would let you edit all the shapes at once.
Image


PS
Don't pay notice of the alternative menu and button graphical look. This is part of a UI project. More info here

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Sun Jan 02, 2005 11:42 pm

Extra Min/Max sliders?
What about ALT LMB for min and ALT RMB max on the actual slider?

And my other crit is, that's taste I guess, it's all button driven.
The good thing is that it explains more, but if I have 14 blend shapes I'll have 14 Display & Edit buttons, when all we need is 1 edit-active (tab). I do like blenders method better: select object, and use a box of tools. So, select blendshape (don't know how) and use tools: Edit, display, ipo color etc. all buttons just ones. They are tools, not representing a state.
I don't know if this policy has changed with the new design.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Mon Jan 03, 2005 5:50 pm

joeri wrote:Extra Min/Max sliders?
What about ALT LMB for min and ALT RMB max on the actual slider?
What? You are complaining about there being min/max settings for the sliders? Well, that's how it is currently in Blender (look in Action window with an RVK object selected, now click the name). If I understand correctly you would want to be able to increase and decrease the min/max settings by holding ALT and dragging the sliders beyond their range? Well, I suppose that'd be nice, but nobody would ever guess that feature - ie. it'd be very unobvious.
joeri wrote:And my other crit is, that's taste I guess, it's all button driven.
The good thing is that it explains more, but if I have 14 blend shapes I'll have 14 Display & Edit buttons, when all we need is 1 edit-active (tab). I do like blenders method better: select object, and use a box of tools. So, select blendshape (don't know how) and use tools: Edit, display, ipo color etc. all buttons just ones. They are tools, not representing a state.
I don't know if this policy has changed with the new design.
Well, you could use the thing in the header I drew above. But I see your point well enough actually - it'd be more compact if there was an ability to select an rvk in the list, and then just have a single set of buttons to operate on them. For the edit and display buttons I can see the advantage, but sometimes you may want to check the other settings and compare them, so you may want to see them at once.

And, the collapsing feature make them very compact if you wish only to see the slider, so I don't really consider it an issue that there is a display button for each shape. The thing is, you'd need to construct some obscure selection system to select the nodes and then find a place for the display/edit buttons - I feel it may only get messier. If you want to only see the sliders and quickly edit a series if shapes, you could enter edit mode and quickly jump between shapes - without even having to have more windows open than the 3d view.

Ofcourse you could construct the system in a completely different way, so if you are thinking of some nice alternative, please spill the beans and show what you're thinking. :)

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri » Mon Jan 03, 2005 6:29 pm

Monkeyboi wrote:
joeri wrote:Extra Min/Max sliders?
What about ALT LMB for min and ALT RMB max on the actual slider?
What? You are complaining about there being min/max settings for the sliders? Well, that's how it is currently in Blender (look in Action window with an RVK object selected, now click the name). If I understand correctly you would want to be able to increase and decrease the min/max settings by holding ALT and dragging the sliders beyond their range? Well, I suppose that'd be nice, but nobody would ever guess that feature - ie. it'd be very unobvious.
Me complaining? I would not know where to start, yes I'm one of the few who don't praise blender as the best of the best, I don't care how much anger that raises, it's only for the best of the patient.

I don't care much for the Action window, it's one big hack

And Pfff, unobvious? . How is that a reason not to do it? :) CTLR = big steps SHIFT-CTRL = small steps. An other modifier to modify is actualy very obvious. But I don't care for obvious, I care for easy of use. A window full of buttons I'm not going to use is (mostly blend shapes will go from 0-1) not very good (IMO). And... all sliders can benefit from ALT LMB for min and ALT RMB for max, without taking up 3x much as space.

"but sometimes you may want to check the other settings and compare them, so you may want to see them at once."

True. But I think your mockup needs a little more work.

Don't get me wrong, It's only my opinion, a consideration for the one who's going to implement it.

Monkeyboi
Posts: 251
Joined: Tue Nov 26, 2002 1:24 pm
Location: Copenhagen, Denmark
Contact:

Post by Monkeyboi » Mon Jan 03, 2005 6:56 pm

joeri wrote:Me complaining? I would not know where to start, yes I'm one of the few who don't praise blender as the best of the best, I don't care how much anger that raises, it's only for the best of the patient.
Hey hey, you misunderstood. If you have a point with a complaint that's fine. It doesn't need to be a negative thing. ;) I don't think Blender is a divine thing either, but it has some very strong points about it, like certain aspects of the interface and some of the tools, as well as the fact that it's free and open source. If the truly lacking areas are fixed (such as the one we are discussing in this thread) it could become a very well balanced all-round application.

joeri wrote:I don't care much for the Action window, it's one big hack.
Exactly, and that's why I think they should be moved.
And Pfff, unobvious? . How is that a reason not to do it? CTLR = big steps SHIFT-CTRL = small steps. An other modifier to modify is actualy very obvious. But I don't care for obvious, I care for easy of use. A window full of buttons I'm not going to use is (mostly blend shapes will go from 0-1) not very good (IMO). And... all sliders can benefit from ALT LMB for min and ALT RMB for max, without taking up 3x much as space.


Yeah, if you applied it universally it might be nice. The trouble is, there are only a handful of sliders where it might work. In fact, I can't think of any other sliders where you'd be able to increase the max value. And if we are only dealing with one specific slider, hiding such a feature (and I maintain that people won't be able to guess that you have to hold ALT to increase the max value) might not be worth it.
joeri wrote:"but sometimes you may want to check the other settings and compare them, so you may want to see them at once."

True. But I think your mockup needs a little more work.
That's a fair opinion, but actually doesn't help. Please give feedback as to what's wrong with it, and even more importantly, how it could be changed. I am only trying to get to the best possible way to implement this, not trying to promote my own proposal. If you have an idea for a correction, feel free to share.

Post Reply