Nate wrote

If you hold ctrl (cmd on Mac) you can start the selection on top of a key. Sorry this is a bit unintuitive to discover!

Oh awesome! I should have just played around with the options keys first. 8)

This is a minor thing that often happens to me... when you want to select multiple keys in the Dopesheet, you have to start your drag from an area where there isn't already a key. Often, though, I have keys all the way down the screen so I have to start dragging outside of the time range I wanted to select. But you are not allowed to click to the left or above the keys (nothing happens).

So say I wanted to select keys from T=0 to T=30; I have to start dragging from T=31. Then if I want to scale the selection to 4x the length (120), I actually need to scale my selection to 124 since it keeps track of how far your keys are from the edge of your drag box and scales them relative to that.

So my wish is that you could drag selection boxes starting above the keys (in the ruler) or there could be some option to size the selection box to just the keys you selected.

Just encountered this... because I want events to trigger, this form of reversing wouldn't work. Also, grabbing all the keys in the editor and dragging them in reverse order doesn't seem to work for me - maybe because ik or constraints don't work the same when you reverse the keys? My character's feet are going through the floor and the animated image regions are twitching at the loop point. It's hard to tell what exactly is off. Edit: It's at least partially becasue if you keyed the "mix" parameter on the first frame, this is now on the last frame, so the ik and constraints only apply for 1 frame.

I was thinking you could sidestep this if there was an option "bake" animations, or at least "bake" them in reverse - basically have it do whatever the "play backward" button does in the editor and key every frame (but also including events in this). So at least it would be easier to make a reverse animation in the editor.

Another idea I had was if it could have an option to export anims in reverse, with "_Reverse" added onto the end.

Yep, I'm using the 3.8 beta right now.

Probably doing something wrong here, but it seems like I can only see one skin at a time? I was thinking the way it worked was that if you wanted separate parts, like left arm, right arm, left leg, right leg, each one would be a skin, and I'd put all the attachments and collisions for each under that skin.

Hmm, okay, maybe I should use that? The hacky thing I've been doing is putting a prefix on all image slots and collision bounds I want to go together (e.g. "leftarm_"), then my in-game object (let's call it Arm) uses that string to only use those collision bounds and only render those parts.

One idea I had for skeleton attachments would be that the attachment is a whole separate file and you choose which animation you want to play on that file in a dropdown, with a boolean for whether it loops forever or plays once, and then animate those attributes.

Is there a way to do this in the editor? I'm thinking it might make it easier when splitting a character up into separately attackable elements (like cannons that you can blow up separately)... you animate the whole thing together but in game you can grab a sub-piece of it and render it separately with a special damage shader as it loses hit points.

fantasyz wrote

I think AxiomVerge maybe suggestion something like tag. Not key/value pair.
Well, if tag is available, it can be used to apply filter too.
e.g. when all parts of head is tagged "head", can do quick filtering to filter out non head parts from the skeleton tree.
Can be done easily by entering the tag name to current search box and auto turn on filter mode with search target switch to tags instead of item names.
But the hierarchy could became very messy when items have too many tags on it unless tag can be optionally hidden from the name.

It is a nice to have feature but I am not sure how much priority will this feature get as there are something more demanded in the TODO list. Most importantly, AxiomVerge is doing fine with parsing the name. :rofl:

It's definitely not the highest priority... many games I've worked on relied on naming bones things like "FootballBone" or "Muzzle0...N" and then the code parses it. I was thinking also maybe I can distinguish Hitboxes from Hurtboxes by changing the color...once I figure out how to read it back out at runtime

Another thing just came up...if there was a way to add properties onto bounding boxes (or maybe just anything in hierarchy in general), so that you could have Hit, Hurt, Collision, Weak Point, etc. as options. The workaround I am using is to make these properties a part of the name and then parse the string.

Late to the party, but for me, the Curve Editor is the most important thing. Just copy Maya's curve editor.

Next up for me would be some automation for image sequences; like you export a sequence (or maybe even a GIF) from whatever sprite tool and the UI could treat it as a single unit where you can key "Begin Playing", "Stop Playing", "FrameRate", etc.

Nate wrote

Yes, but it is not automated. If you have bones controlled by IK, you can select them and key their rotation. This creates FK rotation keys using the rotation value that the IK calculated. These keys are applied and then overridden by the IK constraint, but if you delete the IK constraint or change it's mix to <100, then you'll see the rotation from the FK keys. You'll need to decide how often you want to set FK keys in your animation to get a reasonable approximation of the IK.

Okay, I didn't realize this... I think that it doesn't auto-key rotations in this case so you need to manually click the key. But it does what I was looking for.

Nate wrote

1) Drop all your attachments on the same slot.
2) Select an attachment that is where you want the others to be.
3) Press ctrl+c (cmd+c on Mac) to copy its transform.
4) Select the other attachments in the tree and press ctrl+v (cmd+v on Mac) to apply the copied transform. This modifies the selected attachments, even though they are not visible.

Nate wrote

1) Drop all your attachments on the same slot.
2) Select the attachments you want to position.
3) Drag and drop them on an attachment that is in the position you want. This modifies the selected attachments, even though they are not visible.

Oh wow, either of these makes it a LOT easier. I never tried copy/paste because I was thinking it would try to duplicate the attachment rather than copy the transform.

Nate wrote

>2 bone IK isn't currently possible. This is because 2 bone IK can be solved analytically (there is one correct solution), while >2 bones requires some sort of integration (there are many possible, valid solutions so the resulting pose depends on the poses of previous frames). Currently posing a skeleton is deterministic in that it does not depend on previous frames. For a given animation time, the pose will always be the same. This is convenient for many reasons, but we do plan to allow non-deterministic features eventually (for physics, >2 bone IK, etc). This means you can get different poses based on factors like how often and how many times the animation was previously applied.

You can use the Pose tool, select any number of bones, and then manipulate them using IK. Note this is for manipulation only, not for interpolation during an animation.

As Erikari mentioned, path constraints may be an acceptable workaround.

Thanks for the explanation. I think path constraints my be a bit complex for my needs right now. Looking forward to all the new features you're working on.

Somebody probably already requested this but are IK chains of more than 2 bones in the works? I noticed that if you try to work around this by having multiple chains parenting to each other, it tries to solve one chain until it reaches its limit before moving the second chain, rather than distributing the movement equally among all the bones.

Nate wrote

Just clicking near the bone tip is of course not going to place the target bone exactly at the tip. In 3.6, create a bone and move it to the tip as Erikari suggested. In 3.7, click the child bone, click New -> Bone (which is created at the tip), move the target so it is not a child of the IK bones, create the IK and choose the existing target bone.

Maybe some kind of "snap to bones" option would be good..