search

ArtOfIllusion / ArtOfIllusion

Art of Illusion modeling and rendering suite - core application and tools
http://www.artofillusion.org
GNU General Public License v2.0
71 stars 23 forks source link

Animation engine bug #145

Open peteihis opened 4 years ago

peteihis commented 4 years ago

Some time ago I discovered a minor bug in the animation engine:

If you press one of the number pad keys while the previous animated move is still unfinished, the move to the new position does not start from the current position but again from the beginning of the unfinished move.

This originally appeared somewhere during the big UI update and I'm pretty sure I had fixed it already at some point ... I remember that the fix was pretty simple but I probably don't have that version around any more.

I'll try to get it for 3.1.1 but if not, let's not wait. There is a fair amount of checked in bug fixes already waiting to be released.

peteihis commented 4 years ago

I have left a comment in the code that indicates, that I have done this deliberately.

Unfortunately the comment did not say why, but I believe it is because a SceneCamera (or any camera object) needs a reasonable undo position. It is not a good idea to record an undo position in the middle of an animated move....

The fix is still not very complex, but will not happen today.

Sailsman63 commented 3 years ago

This actually seems related to the discussion around framing imported STL files.

The animation engine should be able to interrupt itself, or queue commands to be executed once the current movement is completed.

peteihis commented 3 years ago

Yes, they are close relatives. :)

The original version of the engine interrupted a view rotation and aimed to the next one directly from that state. It did not do any queuing. Now after the discussion around the STL-Translator I think I have a pretty good idea how to handle it.

The idea is based on queuing, but rather than performing all the individual steps after one another it would calculate the queue trough and aim for the result from where ever it is, when a new request is entered. I was actually sketching a very similar approach to the occasional 'scroll wheel slipping' problem. I think this should work for most of the cases.

The logic when and where to drop a bound camera object or when to keep it needs to be chewed through. All the information is in the user commands but cameras must not be dropped in the middle of any queued move.

Can't say when I can sit down at it, but soonish I hope. But promise, it's in the back processing silently.