PDA

View Full Version : Fixed Autokey mode, Multi-Selection Editing of Modifiers. etc..



hypersuperduper
12-12-2017, 09:17 AM
Now that we have a release date, can we PLEEEEASE start geeking out about features again.

Most of the stuff we have seen before but I wonder what the extra features at the bottom of the 2018 feature list are.

Multi-Selection Editing of Modifiers seems like it could be a real timesaver, because right now it is a real thorn in my side that we don't have that.

does that include node networks? Tell me! Tell me!

Fixed Autokey? whats that?
Questions! Questions!

Matt
12-12-2017, 10:36 AM
Multi-Selection Editing of Modifiers seems like it could be a real timesaver, because right now it is a real thorn in my side that we don't have that.

does that include node networks? Tell me! Tell me!

Not in terms of editing the contents inside node networks, but the adding / removing / copy / pasting of modifiers.


Fixed Autokey? whats that?

Allows you to specify a keyframe to _always_ key on no matter where you are on the timeline.

Chris S. (Fez)
12-12-2017, 10:44 AM
Matt, there is no mention of improved mesh performance in the marketing material. Did the new mesh engine mentioned on the blog not work out?

Matt
12-12-2017, 10:47 AM
Matt, there is no mention of improved mesh performance in the marketing material. Did the new mesh engine mentioned on the blog not work out?

Layout does have speed increases when dealing with meshes yes.

Chris S. (Fez)
12-12-2017, 10:55 AM
Layout does have speed increases when dealing with meshes yes.

Great. Thanks.

hypersuperduper
12-12-2017, 11:22 AM
Not in terms of editing the contents inside node networks, but the adding / removing / copy / pasting of modifiers.



Allows you to specify a keyframe to _always_ key on no matter where you are on the timeline.

So does this mean I can edit a node network and then copy paste it to multiple objects at once without having to cycle through them?

Always key seems like a great addition sort of the opposite of the way Maya blender etc. do it but I don’t see why it won’t work.

GraphXs
12-12-2017, 12:10 PM
Fixed Autokey Mode: YAY YAY, no more creating keys at the wrong frame. Nice little addition! I know the Maya folks will like that!

hypersuperduper
12-12-2017, 12:22 PM
Not in terms of editing the contents inside node networks, but the adding / removing / copy / pasting of modifiers.



Allows you to specify a keyframe to _always_ key on no matter where you are on the timeline.
Thanks for the info! It’s like Christmas. Could you elaborate on the layer improvements in modeler?

Matt
12-12-2017, 01:00 PM
Thanks for the info! It’s like Christmas. Could you elaborate on the layer improvements in modeler?

Scripts to manage working with layers better:

Search Layers - Allows setting of FG / BG layers from a searchable list
Find On Layer - Finds which layers polys reside on by setting the FG layer of any selected polys
Next Layer - Advances all selected FG layers by 1 but keeps any BG layers you had selected (until a selected FG layer replaces a BG layer)
Page Down hotkey re-assigned from 'Next Lyr Bank' to 'Next Layer'
Prev Layer - Decreases all selected FG layers by 1 but keeps any BG layers you had selected (until a selected FG layer replaces a BG layer)
Page Up hotkey re-assigned from 'Prev Lyr Bank' to 'Prev Layer'
Select All FG Layers - Selects all FG layers but keeps any BG layers you had selected
Select All BG Layers - Selects all BG layers but keeps any FG layers you had selected
Select FG Lyr Range - Fills foreground layers between two foreground layer selections
Select BG Lyr Range - Fills background layers between two background layer selections
Insert / Delete Layers - Respect pivot points


Also added:

Reassign Surface - Allows reassigning of surfaces based on a name search match
Select Surfaces - Allows selection / deselection of surface names using a list of surfaces versus the single selection in the Stats panel
Rotate To Axis - Allows rotation of geometry to XYZ axis using the normal of the first poly selected as a reference for rotation

jboudreau
12-12-2017, 08:37 PM
Scripts to manage working with layers better:

Search Layers - Allows setting of FG / BG layers from a searchable list
Find On Layer - Finds which layers polys reside on by setting the FG layer of any selected polys
Next Layer - Advances all selected FG layers by 1 but keeps any BG layers you had selected (until a selected FG layer replaces a BG layer)
Page Down hotkey re-assigned from 'Next Lyr Bank' to 'Next Layer'
Prev Layer - Decreases all selected FG layers by 1 but keeps any BG layers you had selected (until a selected FG layer replaces a BG layer)
Page Up hotkey re-assigned from 'Prev Lyr Bank' to 'Prev Layer'
Select All FG Layers - Selects all FG layers but keeps any BG layers you had selected
Select All BG Layers - Selects all BG layers but keeps any FG layers you had selected
Select FG Lyr Range - Fills foreground layers between two foreground layer selections
Select BG Lyr Range - Fills background layers between two background layer selections
Insert / Delete Layers - Respect pivot points


Also added:

Reassign Surface - Allows reassigning of surfaces based on a name search match
Select Surfaces - Allows selection / deselection of surface names using a list of surfaces versus the single selection in the Stats panel
Rotate To Axis - Allows rotation of geometry to XYZ axis using the normal of the first poly selected as a reference for rotation


Are these scripts that you made?

jeric_synergy
07-20-2018, 11:15 AM
This one slipped by me: Auto Key: FIXED


Allows you to specify a keyframe to _always_ key on no matter where you are on the timeline.

This is a way of getting the feature I prefer to call "STATIC ITEM". Glad to see it got implemented.

jwiede
07-20-2018, 03:00 PM
IMO, it seems like "Auto Key: Fixed" is somewhat orthogonal to a couple of the other auto-keying options, specifically "existing", "modified" and "all". Put another way, whether I want auto-keying fixed to a given keyframe is an independent decision from the channels I'm allowing auto-key to alter.

It really needs four controls: A checkbox for activating/deactivating auto-keying, a drop-down for selecting whether auto-keying affects existing|modified|all, a checkbox for whether to auto-key to a specific frame (aka "Fixed"), and a numeric field for which frame number receives fixed auto-keying. If fixed is always frame zero, the last field can be omitted. The way the controls work now, using fixed-frame auto-keying needlessly blocks users' ability to control which channels auto-keying is allowed to impact.

Filed as LWF-1967.

Matt
07-20-2018, 04:39 PM
A checkbox for activating/deactivating auto-keying


a numeric field for which frame number receives fixed auto-keying

It has both of these.

jwiede
07-20-2018, 05:57 PM
It has both of these.

I think you're missing my point. The issue is that, given the existing controls, you can't turn on fixed-frame and also control which channels auto-keying alters. I was proposing a set that would allow access to controlling both fixed frame, and also what channels auto-keying alters. See LWF-1967 as well.

I wasn't saying it didn't have ANY of those controls I listed. However, having both of those doesn't solve the issue.

Also, w.r.t. frame #, opening "General options" allows (well, is supposed to allow) access to the setting defaults, but in the case of frame #, it's not really accessing the default frame # value, it's accessing the current frame # value. Is that worth filing as a bug by itself, or is LWF-1967 adequate?

I know there are a bunch of other "current-masquerading-as-default" fields in prefs. However, in that specific case, the Auto-keying control immediately above explicitly says "default". I'll argue it's ambiguous/confusing UX for Auto-key frame # to access "current".

jeric_synergy
07-20-2018, 06:41 PM
https://www.lightwave3d.com/account/report/LWB-4200/

I've reported there's no dox currently for FIXED, and there's something that is worrisome: if a user engages FIXED mode, does it ERASE all existing keyframes?

::test test test:: No, it does not, but it IS wierd: Animate an item along a path without FIXED engaged, w/like 5 keyframes, including frame zero. Engage FIXED. Now put the timeline cursor at , oh, 60, and move the item.

I'm not sure what's happening, but it's weird, and it doesn't seem like the frame zero keyframe is being updated. It's very puzzling.

Frankly, it would be BETTER, or at least less confusing, if engaging FIXED destroyed all other keys. At the very least, the current behavior requires documentation to make clear what's happening.

ADDENDUM: ....nah, still confusing. Really, guys, STATIC CHANNEL did it correctly.

jeric_synergy
07-21-2018, 08:59 AM
OK, fwiw, here's my opinion as to how FIXED should work:


For any given item, engaging FIXED sets a keyframe at the present P/R/S, on the designated Preferences frame #,

and disables all other keyframes:

Whether these keyframes are destroyed or somehow preserved (footprints? on a 'special' channel(s)?) is up to the devs.




Usually, wanton keyframe destruction isn't good, so perhaps a (leveled) Alert could be thrown up first.

jwiede
07-21-2018, 06:36 PM
I really believe the way LW approaches auto-keying, and static animation-type items needs a more general redesign.

First off, I'd recommend segregating "general scene entity animation properties" from auto-keying, because the latter is independent from, and broader in scope than, the former. I actually agree with you that having an "animation type" for an object that's "static" (as opposed to "anim-driven"/"dynamic-driven"/"hybrid-driven"), with a default pref for frame #, and a per-scene "current" static frame # property, is probably the best of handling that situation. Each scene entity should have a property for "animation type", defaulting to "static"/"frame#=0" unless default prefs changed.

As noted, desirable auto-keying settings are really independent of where an entity's animation (if any) originates. For auto-keying, having default prefs for "on/off" & "existing"/"modified"/"all", as well as (independent) per-scene-entity "current" properties for same, would likely be quite adequate. The big change there versus current LW is the per-scene-entity/grouping aspect. In complex scenes there often wind up being different groups of entities where optimal auto-keying varies by entity (really, by groups of entities, as different types of entities grow in the scene).

Some sort of multi-select behavior, combined with a per-entity "current" scene property for auto-keying behavior, would represent a baseline level of control. However, I'd recommend it be a property that could be assigned to a group, where moving the entity into that group sets that entity's properties to match the group-set properties. There's a broader recommendation there about a mechanism to allow creating groups and assigning per-entity properties to groups so the groups serve as "templates" for per-entity property settings, but that's a separate discussion.

If devs wanted to get really fancy, they could even define different auto-keying prefs defaults (and per-scene "current" values) for the different "animation-types" (per above), as "animation-type" entities also typically merit different auto-keying behaviors. While "existing" or "modified" is generally more efficient for "static" animation-type entities, "anim-driven" entities are more likely to benefit from "modified" or "all". "Hybrid-driven" (where animation triggers dynamics or gets applied post-dynamic-simulation-range) are cases where unwanted keyframes cause issues, so "auto-keying off" or (on+)"existing" are generally most beneficial there. Likewise, "Dynamic-driven" most often benefit either from "off", though in the cases where dynamics settings are being animated, "existing" or "modified" may make more sense.

Obviously, implementing such an arrangement would require numerous changes to LW, but would provide a system that is cleaner and easier to understand. Compared to the current approach where prefs defaults, "current" settings, etc. for auto-keying enabling and channel behaviors, and "fixed-keying frame #" are all kind of overlapped, such that controls' behavior and impact on defaults/"currents"/etc. in scene are difficult to predict, the approach I've described would be much easier to understand (IMO). Further, the actual changes required to implement it are quite direct, and mostly just separating currently-overlapped controls' purposes/meaning.

Just a suggestion -- added to LWF-1967.

jwiede
07-23-2018, 02:42 PM
First off, I'd recommend segregating "general scene entity animation properties" from auto-keying, because the latter is independent from, and broader in scope than, the former.

(sigh) Too late to edit, but I used "latter" where meant "former" and vice versa in that sentence. I restructured the sentence in an edit, and never fixed that part. Oh well, mea culpa.

hypersuperduper
07-24-2018, 03:08 AM
I don't feel like lw's auto-keying needs a whole redesign. Blender, maya, aftereffects and others i am sure all basically require the user to manually activate a channel before it can be animated, otherwise it is considered static (or assigned some other driver instead of keyframes). And which channels are active is contained in the object, which seems similar to what is being suggested here more or less. Lightwave's approach as with most things is more direct. if you move something it will make keyframes unless you specifically tell it not to, and as a user you need to be more conscious about keeping the channels clean and getting rid of unwanted keys, and you are given a number of tools to make this easier. I am not entirely sure which method I prefer, honestly, but I think that the Lightwave team probably should think VERY carefully before adopting a whole other key-framing paradigm.

As for Autokey=fixed. I dont like it the way it works AT ALL. It features too many unintuitive behaviors and I feel should be redone completely.

Issue one for me is undo. Undo and autokey=fixed are completely incompatible. if I am on key 30 and move an object with autokey=fixed set to 0 it will modify the keys at frame 0 as expected, but if I Undo it will move the item back to its original position at frame 30, but it will not revert the key at frame 0. This is unacceptable even by Lightwave undo standards.

The other issue is that I question the value of a tool that simply makes a keyframe at an arbitrary frame that is not the one you are on. It is a hack to fix a issue that Lightwave's always-on keyframing paradigm creates.

A far better way to approach autokey=fixed would be to add the transformation the user makes in the viewport or numeric input to EVERY existing key, so that the behavior would be the same as dragging a channel up or down in the graph editor, that way you could quickly and easily shift an entire motion in addition to having a key framing mode that provides the advantages of static objects. Naturally, undo should be fully compatible.

jwiede
07-24-2018, 12:46 PM
BTW, if setting a scene to "Auto-key Fixed" in the viewport UI (or the prefs) and assigning a frame # in prefs is supposed to be saved with the scene, that isn't what's actually occurring (on Mac LW, anyway).

While the prefs & viewport auto-key setting values appear to be saved in LW configs, neither appears to get saved in the scene (where viewport gadget setting should). Meanwhile, the "frame number" appears to ONLY be saved in the scene, and never in the LW configs. That combination means a setting of auto-key:fixed and a frame number is never correctly captured anywhere.

Reloading a scene reloads the frame-number pref/'current' setting, but it's useless because the auto-key:fixed setting has been lost, potentially leading to effectively scene-corrupting auto-keying behavior (creating keyframes elsewhere than the fixed frame number). Likewise, attempting to set a frame number in the prefs as default won't work, because it's not stored in the prefs/configs, it's only ever stored in the scene.

Filing as bug shortly.

Matt
07-24-2018, 01:08 PM
I think you're missing my point.

I understand what you're saying, I was merely pointing out some of the features you mentioned existed already

jwiede
07-24-2018, 01:33 PM
I understand what you're saying, I was merely pointing out some of the features you mentioned existed already

Understood. I was focused more about the way they interact, and are stored (or, more accurately, [i]aren't[i] stored) -- that creates both functional and UX issues.

Is "auto-key:fixed" already slated for rework?

I'm trying to decide how many "bug filings" it's really worth. I've got a long list of testing on my to-do list (for third-party plugins as well as LW), and filing a bunch of finesse-detail bugs isn't worthwhile if the mechanism's already slated for significant rework.

jeric_synergy
07-24-2018, 11:36 PM
The other issue is that I question the value of a tool that simply makes a keyframe at an arbitrary frame that is not the one you are on. It is a hack to fix a issue that Lightwave's always-on keyframing paradigm creates.

Sadly, I must concur: although I specifically requested this feature, I am not liking the implementation, and as you state, a lot of it is due to existing keyframing practice.

A pity.

Besides the Undo issues mentioned here, there are the previously mentioned issues of turning FIXED "on" for an object that already has keyframes. Unlike the channel modifier STATIC CHANNEL, it does not pro-actively go and delete existing keyframes, which just makes the subsequent behavior confusing.

Give it another try, devs.