Delay in vector shape morphing

Hi all. I have a series of dogs morphing one into another. Works fine - with the exception of the first dog morphing into the second. There´s a delay and the transition is jumpy - even worse on mobile phone. Any ideas?

Thanks in advance and best regards,
Kalle (91.6 KB)

Final result here:


Just a hunch… the first shape has maybe too many anchor points. More then the rest it seams.

a direct morphing (less effort) works …


What do you meen by ‘direct morphing’?

Hmmm, but it works perfectly when you start over…

ah es gibt doch zwei Modi für das Morphing :slight_smile:

1 Like

@h_classen means the “Formmorphing” following…
changed to the following…

1 Like

Thanks Max, found it already :slight_smile: Wasn´t aware… :slight_smile: Just don´t like the results with direct morphing in this case. Just changed the first morph - works and looks ok…

1 Like

Ok, works pretty well as described (see above):


Slightly off topic but as I watch your morphs I was reminded of …

I would love if we could set morphs to none intersecting so the lines do not cross over.

But suspect not really feasible in regards in what we would gain against how much programming that would take. (Likely a lot of programming just thinking about it)

Reminded of what…? :thinking::grinning:

Of what written below that i.e something thst had been on my mind.

1 Like

Sorry I’m late to the thread, but I wanted to weigh in on this cool shape morph and expand with a few more details/answers.

This is basically the case; the shape morph is computationally expensive to compute. There are actually three options you can choose from to address it:

  1. Use the Direct Anchor Point Match (as @h_classen and @MaxZieb showed) for the Shape Morph Algorithm option. This is akin to a “manual mode” and just lines up each anchor point from one shape to the next and interpolates between them. If there are extra/fewer anchor points they will get added or removed from the end of the shape.
  2. Reduce the number of anchor points/shape complexity. This will just reduce computation time since there’s less to calculate. It sounds like you took this approach.
  3. Pre-calculate the shape morph. The first time the Hype runtime encounters hitting a shape morph algorithm, it does a lot of calculation to determine the best morph. This data will get cached by the runtime so if there are subsequent animations it will be much faster – basically it is doing a direct anchor point match after this calculation. So if a particular morph is taking a while to get going, you could do a technique where on scene load you move the playhead to a point within the animation. This will cause the runtime to do the heavy calculations and cache the data. In your case, having a Go to Time in Timeline action of 0:00.01 and then optionally back to 0:00.00.

Absolutely! There’s probably some different ways to accomplish this that might be quicker than others. It doesn’t necessarily mean that the anchor points need to be super clever in their movements. For example, right now the Best Match algorithm runs a lot of possible iterations and uses ranking to determine which is the best. An intersection could be a factor in the ranking, and that might not be too bad. It would of course require experimentation :slight_smile:.

Any future algorithm changes will not affect existing animations; there would be a new algorithm choice in the UI.

This is great! Is it part of an article? I’d love to share on our channels more widely since Shape Morphing is a feature we want to promote usage of :slight_smile:.


Pre-calculate the shape morph…

Thanks Jonathan, I was thinking of similar things, but didn´t work. I´ll test your aproach.

Unfortunately not (yet). I did this more just for fun, just to get a feeling for shape morphing. As soon as there is a URL with the graphic as part of an article I´ll pass it to you.

1 Like