Page 2 of 2 FirstFirst 12
Results 16 to 23 of 23

Thread: Fixed Autokey mode, Multi-Selection Editing of Modifiers. etc..

  1. #16
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732

    Lightbulb how AUTOKEY: FIXED >>should<< work, IMO

    OK, fwiw, here's my opinion as to how FIXED should work:

    1. For any given item, engaging FIXED sets a keyframe at the present P/R/S, on the designated Preferences frame #,
    2. and disables all other keyframes:
    3. 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.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

  2. #17
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    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.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  3. #18
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    Quote Originally Posted by jwiede View Post
    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.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  4. #19
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    587
    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.
    Last edited by hypersuperduper; 07-24-2018 at 03:21 AM.

  5. #20
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    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.
    Last edited by jwiede; 07-24-2018 at 01:06 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  6. #21
    Valiant NewTeKnight Matt's Avatar
    Join Date
    Feb 2003
    Location
    San Antonio, Texas, USA
    Posts
    13,055
    Quote Originally Posted by jwiede View Post
    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
    UI / UX Designer @ NewTek
    __________________________________________________
    www.pixsim.co.uk : LightWave Video Tutorials & Tools


  7. #22
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,513
    Quote Originally Posted by Matt View Post
    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.
    Last edited by jwiede; 07-24-2018 at 01:36 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  8. #23
    Axes grinder- Dongle #99
    Join Date
    Jul 2003
    Location
    Seattle
    Posts
    14,732

    Unhappy

    Quote Originally Posted by hypersuperduper View Post
    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.
    They only call it 'class warfare' when we fight back.
    Praise to Buddha! #resist
    Chard's Credo-"Documentation is PART of the Interface"
    Film the cops. Always FILM THE COPS. Use this app.

Page 2 of 2 FirstFirst 12

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •