Search options (Page 12 of 136)

So if I understand correctly you would rather track every joint independently with the trajectory tool and then later be able to bind say an angle object's points to these trajectories. Something like creating a new angle object and having an "Attach to trajectories" menu where you can assign each point to one of the existing trajectory objects. Does that sound correct?

This might be simpler to implement than the full conversion between object types I was thinking about. Ideally this mapping would be temporary so that you could assign the angle object to another set of 3 trajectories.

What should happen if the selected trajectories don't have the same start/stop frames? I imagine the angle would just keep the last known value for each point.

I guess with this approach it would also be interesting to leave one or two points unassigned or assign them to a static marker. In any case it must work in the case the bound trajectory object is deleted at some point.

Version 2024.1 is in the phase where it's published but I'm waiting a bit to see if someone reports a catastrophic bug before setting up the main page link.

Yes, this has been a problem for a long time and I want to address it.

There are two directions: 1. improving tracked drawings interface to have the same utilities as the trajectory, and 2. being able to convert multiple trajectories into a single drawing. The second one is interesting but feels much more complex in terms of logistics. The first one is important to have anyway, so I think it will start in this direction.

One of the next things I intend to do is move the drawings' configuration dialog to the new right-hand side panel and it looks like the tracking configuration for drawings and trajectories could be moved in a tab there as well.

It will probably always be necessary to correct multiple points at the same time since the tracking might fail only for one tracked point of the drawing.

The last 32-bit version is 0.8.27, you can get it in the download page.

If it's on the text tool you can increase the font size. I'm assuming the 4K video is getting downsized and it hits the part of the code that prevents the labels to become very small in the user interface. So they appear larger than what they really are only in the player window. The export is at the original image size so it respects the font size from the tool configuration.

If changing the size just by one or two steps doesn't appear to make a difference it's definitely this. Increase the size from the tool configuration until you can see the text actually getting larger again, then at that point it should match the export.

Soon™ :-) I'm updating the translation files for the new strings added since the last version, which is one of the last steps. New version should be out before the end of the month.

Yes you're right it's currently a limitation of this that it works in screen space and not parallel to the coordinate system axes. I'll add this to the bug tracker to remember it.