Following on from my previous set of Blender 2.5 FAQ's, here are some more FAQ's that are now cropping up (or that I missed from the original list). Enjoy.
From the animation corner...
How do I make my animation repeat? Where has Cyclic Extrapolation gone?
In the dark old days, there were 3 ways to cycle your animations:
1) Manually copy all your keyframes for each repeat you wanted (not really recommended)
2) Add the action as a NLA Strip, and adjust the repeat settings
3) Use "Cyclic" Extrapolation mode for the IPO-Curve
Indeed the first two options still work in 2.5, though there have been some changes to the NLA route to avoid some of the problems people were running into a lot in the past. Instead, I'll talk about 3), which is what most people asking this have come up against.
With 2.5's animation system, I've introduced the concept of "FModifiers", which allow performing some sort of (procedural) operation on the values (and even timings) of F-Curves, so that the final "result" of looking at the F-Curve on some frame . The poster child here I guess is the "Noise" F-Modifier, which allows adding subtle (pseudo-)random variations to your F-Curves, which is a neat way to add more realism to certain motion sometimes, as well as being potentially good for simulating lightning.
The "cyclic" extrapolation options have now been made F-Modifiers as they fit in better in that framework than as a hack that affected the way that the extrapolation code worked. A key side effect of this is that it is now possible to specify how this cyclic behaviour occurs, with new options for controlling the number of cycles before/after will happen, and also how these cycles happen (i.e. mirroring/ping-pong).
Also, as an F-Modifier, you can see what stage of the evaluation process it occurs at, as opposed to before, when it was something that happened in the backend, and somehow worked. By fitting in this framework, the results can modulated (i.e. influence toned down or tweaked) by applying "Envelope" F-Modifiers on top of them, so you can even fade out the cycling effect over time.
This leads to the next question...
How do you add a F-Modifier?
A FModifier can be added to an 'active' F-Curve's modifier stack the using the "Add Modifier" button in the NKEY Properties region. This only adds the F-Modifier to the 'active' F-Curve whose settings appear there, which may not be so practical at all times.
Instead, there is also another way that it seems not many people are aware of.
1) With the mouse over the Channels List, expand all the entries. This can be done with the NUMPAD+PLUSKEY hotkey (or from the "Channels" menu). You may need to do this a few times before the F-Curves are all visible.
2) Select all the relevant F-Curves to add the F-Modifier(s) to. To do this efficiently, you may want to consider using some of the filtering options to restrict the channels displayed to just the ones you want to work with, and then just using AKEY to select all of them. See "Tips for Editing Animation in 2.5 - Part 2" (yet to be posted) for more details on how.
3) Ctrl-Shift-M with the mouse of the keyframes area. This presents a menu with the choices of F-Modifier that will get added to ALL the selected F-Curves.
Where has the "Record Mouse" tool in the IPO Editor gone?
The "Record Mouse" tool has been removed, as it was quite restrictive (only being able to do 2 channels at once) and also against the design principles for 2.5 in general (modal, initial menu, only worked for settings that showed up in IPO Editor).
However, there is a much better alternative (for most cases where you used the old tool at least)! Simply enable Auto-Keyframing, start playback, and select+move Objects and/or parts of your rigs to record the 3D-motions in realtime. Not only does this give you better feedback of the end results of doing this (for recording naturalistic "live" motions, especially dance-like jiggling), but it is more natural to set up.
The downside is that it becomes harder to do this for other channels such as colour. However, for that, you can always animate a dummy object first, and then copy all the keyframes over, or even just drive those settings by the appropriate channels from the dummy object.
Where has animation playback (Scene->Anim->PLAY) gone?
This question refers to the playback of rendered animation within Blender.
The animation playback tool functionality has not been restored yet, as it required quite a bit of work getting it under control again for the 2.5 architecture, which is something nobody had time to do back when a decision was made on what to do with it.
Instead, a python script for activating an external player to play back these files was added by Matt, which can be used from Render -> Playback Rendered Animation (Ctrl F11).
To set the player to use:
1) Open User Preferences (File -> User Preferences...)
2) Go to the "File" tab
3) Set the "Animation Player" type and specify the path to the binary in the text-field beside this.
To use the old Blender playback tool, you'll need to have a copy of 2.4x still hanging around on your computer.
1) Pick "Blender 2.4" as the player type
2) Find the "blender.exe" (or whatever the extension is for your OS) for the Blender 2.4 binary. NOTE: it is "blender" not "blenderplayer" as some people have incorrectly stated sometimes on BA.org ("blenderplayer" is the nearly-always-defunct tool/platform for running/playing Game Engine games without going through Blender first and pressing P)
From what I've heard though, "djv" is quite a capable and more functional alternative that you may want to consider instead.
Modelling Stuff
When's Bevel coming back? When do we get a "real" bevel tool that works?
Personally, I don't really have much of a need for this, so I'm not really as concerned about this as some people are. From what I do know though, this is not going to come about too soon.
To code a better Bevel too (or any mesh tool for that matter), BMesh - the new mesh system - needs to be completed, stabilised, and in trunk. However, simply getting BMesh in trunk does not mean that a better Bevel comes with it as well. It's really an additional development that can take place subsequently as a result of these developments, not as a primary goal for BMesh.
Otherwise, BMesh is really just going to become "the mythical BMesh".
When is there going to be a better Knife tool?
I agree the current knife tool sucks. But, in this case, it is something that the BMesh refactor can easily fix, and is probably a goal for it.
So, the question really becomes: When will BMesh be ready?
How do you use Knife tool in Blender 2.5? The knife options menu doesn't show up!
As part of the initial 2.5 tool cleanup work, there was a push to try and make operators less modal and less "how do you want to hang yourself today" (a reference to Microsoft's former slogan and interaction design paradigm). For the knife tool, this meant getting rid of the confirmation menu so that the tools were more "direct".
The net result is that to use the knife tool, you now:
1) Hold KKEY
2) LMB-Drag to define the knife cut
3) Release LMB to finish the cut
This does a "Free" knife cut. If you want a "Midpoint" one, replace step 1 with
1) Hold SHIFT-KKEY
and continue as before.
Currently, there isn't another hotkey assigned for the other option, but you could easily add that using the keymap editor if you needed it.
I should also add a disclaimer here about trying to change the cut type (or another one of the other settings) from the "Last Operator Panel" in the toolbar region. As anybody who tries to do so will find, trying to change the cut type from here will not work (and in early versions would even crash). This is because the context information is not correct. The panel is located in the "toolbar region" instead of a "viewport region", so after changing the property, when the operator is rerun to try and execute it with the new settings, nothing will happen as the operator requries a "viewport region". Trying to infer this information is not possible from the current view (case in point: what happens with a four-split 3d-view?). It should however work if you used the F6 last operator settings popup while hovering over the right region though.
What happened to the Bridge/Skin-Faces tool?
This was removed after a short incarnation in 2.5, due to some problems/incompatibilities. However, will probably get restored again once BMesh is done as a proper tool using that API.
When will BMesh be ready?
I don't know exactly what the plans are with this, as they seem to change every few weeks.
Sometimes the plan is to have it before the "stable" 2.5 so that we have usable modelling tools and less breakage. However, more likely is that it is going to be one of the post-2.5 releases. That is, BMesh really wasn't originally a target for the "2.5 project", but rather something that may come along with or as a result of work on 2.5.
Also, a lot of the status of BMesh depends on joeedh, who is really the main/only developer really working on this consistently. With Animation Mentor commitments, and ongoing health concerns, he does have a bit on his plate. However, he is committed to finishing work on this.
So, hopefully this doesn't stay too much in the "mythical" category as 2.5 once was for much longer :)
UI Stuff
Why does text appear in the scrollbars? (see here and here)
The scrollbar design in 2.5 tries to be a minimalist/sexy by not solidly occupying a chunk of space, obscuring anything running behind it like traditional Windows ones for example. Instead, it is more of a semi-transparent floating rounded "tube" that sits over the top of the content.
In some cases, this allows you to use line up other things such as the frame cursor with the scrollbar markings better. The other consequence of this is that sometimes, underlying text can show through onto the scrollbar. However, it's not really a bug, and I don't really think it's that's distracting in practice.
What's up with the "horizontal" buttons layout? When's it coming back? Help, the button layouts explode! What about the "Free" layout?
First off, a decision was made by "the UI mafia" to go with Vertical only. The main reasons are...
1) Vertical is the more natural orientation for lists of data (i.e. Constraints, Modifiers) of arbitrary length, and we have quite a few of these that need to be displayed
2) Grouping buttons into panels based upon common-context/functionality means that some panels will have more settings associated with them than others. This means that you'll either have to make the panels larger to keep laying out the buttons nicely, or keep the panels the same sizes but pack the content tighter. Either way, you'll have problems (it becomes difficult to tell how big a panel is and then you'll have to scroll two ways to navigate all the buttons; OR button layouts get really cramped, with cryptic names and not-so-obvious layout) if a horizontal layout is used. However, using a vertical layout means that panels can be different sizes, nice buttons layouts don't have to be sacrificed for trying to fit buttons within a fixed space, and you'll have single-axis scrolling only to worry about.
Therefore, the Blender 2.5 buttons layouts are really optimised for the vertical layout ONLY, as they really represent the most scalable way to display heaps of functionality. This does mean though, that other layouts cannot work well with these same button layouts, as now the panels are really very different in height - favouring tall and variable height layouts.
You may ask then why we don't have an alternative layout for horizontal, or even better an automated way to flatten out these layouts so that they work in horizontal. Having a separate set of layouts turns out to be a maintainability nightmare, as options must be added to both sets of layouts every time they're added or changed, which simply will not happen (the situation with the various buildsystems for compiling Blender should act as a clear warning to anybody who thinks otherwise, as coders will frequently only update/thoroughly-test their own buildsystem and let the others languish). As far as automated ways go, it can be tricky to say where to draw the line to split, but then the layouts would almost certainly be non-optimal.
So really, the chances of it coming back are close to 0. Probably not the news you wanted to hear, but that's the nature of some changes.
However, I can sympathise a bit with those users who like using horizontal layouts more. I too used to mostly use horizontal, except when rigging and animating, when vertical was always a better choice (for showing lists of constraints, bones, etc.) I can also think that horizontal layouts ultimately allow quicker access to a fixed set of tools, because more items can be placed and seen at any time horizontally than vertically without needing to scroll (especially on newer-style displays, where the width of a screen is several times its height), not to mention horizontal movement being easier with the mouse than vertical. Regarding the scrolling issue, I do think that it is a bit significant with some of the layouts we've got now, where you do end up scrolling up/down a bit - though that's really more symptomatic of some ordering and grouping problems instead IMO.
Speaking of problems, the explosion problems are know about, and have been logged in the tracker numerous times before (IIRC, I logged one of the first reports on it ages ago), so we really have enough reports on it already :)
No comments:
Post a Comment