<p>This is a pure optimisation problem. It depends on many factors like:</p>

<ul>
<li>What you need to do with the tween</li>
<li>How many different tweens you need to calculate</li>
<li>How much signaling between systems you need</li>
<li>Whether you need to use that data in your CPU bound process or not.</li>
<li>How much time you have to write the code</li>
<li>What your tool set supports easiest</li>
<li>...</li>
</ul>

<p>See if you only need one value to interpolate then your CPU is more than likely faster (unless you're running some weird embedded system). Even if you move a bunch of points you can still calculate the tween of that one position and do the needed cluster transformation in the GPU, like bone animation.</p>

<p>The GPU only starts to win against your processor if you need to calculate many truly separate animation curves in parallel. Or you're in an otherwise performance bound system like running JavaScript in a WebGL application. If you do use the GPU then it's most likely best to tween all vertices, at least unless your object is somehow massive. Since initiating a new draw call is costly and maintaining many states is more complex. Its just that those vertices that don't move would just move from starting point to starting point.</p>

CC BY-SA 3.0
2017-04-04T23:14:38.323Z
I suppose I'd like to animate any numbers of particles to randomly chosen end points. It could be 100000 particles (where a particle could possibly have multiple vertices). It's a personal project for fun, so no time limit. I don't need the data on the CPU side, but I just need to know when the tween is complete on the CPU side.
trusktr
CC BY-SA 3.0
2017-03-29T22:07:39.817Z
2017-03-30T06:53:44.660Z
2017-03-30T06:53:44.660Z
joojaa
<p>I was thinking that I could pass a timestamp in (from requestAnimationFrame) to the vert shader, and just have my easing curves in the GPU instead of using (for example) Tween.js from the outside.</p>

<p>Is this a good idea? Why or why not?</p>

<p>EDIT: After learning more GL and thinking about it, it doesn't seem like I want <em>every</em> shader instance to run a tween that I may only use for a handful of vertices. Can we have only certain shaders run tween calculations if the vertex being animated is the one of the current shader?</p>

CC BY-SA 3.0
2017-03-28T05:05:54.023Z
Please dont ask for oppinions. They dont give out clear answers. Yes, it works.
joojaa
CC BY-SA 3.0
2017-03-28T17:55:35.973Z
@joojaa Some answers can be based on widely-held community opinions called "conventions", which I may not know of, which is why I'm asking. After thinking about it, it doesn't seem like I want *every* shader instance to run a tween that I may only want for a handful of vertices.
trusktr
CC BY-SA 3.0
2017-03-28T18:33:00.740Z
Im fine with the other parts except is it a good idea. Since good is not well defined. This is not a convention thing as its merely a optimization problem, neither is clearly better in a context free situation. But we can not optimize in all possible contexts.
joojaa
CC BY-SA 3.0
2017-04-04T23:15:37.567Z
@joojaa Suppose we're animating 100000 vertices to randomly-chosen end points.
trusktr
<opengl><shader><glsl><webgl><javascript>
Easing curves on the GPU?
trusktr
# Easing curves on the GPU?

(Asked by: username_0 on 2017-03-28)

I was thinking that I could pass a timestamp in (from requestAnimationFrame) to the vert shader, and just have my easing curves in the GPU instead of using (for example) Tween.js from the outside.

Is this a good idea? Why or why not?

EDIT: After learning more GL and thinking about it, it doesn't seem like I want *every* shader instance to run a tween that I may only use for a handful of vertices. Can we have only certain shaders run tween calculations if the vertex being animated is the one of the current shader?

**Tags:** opengl, shader, glsl, webgl, javascript

> **Comments:**
> **username_1**: Please dont ask for oppinions. They dont give out clear answers. Yes, it works.  
> **username_0**: @username_1 Some answers can be based on widely-held community opinions called "conventions", which I may not know of, which is why I'm asking. After thinking about it, it doesn't seem like I want *every* shader instance to run a tween that I may only want for a handful of vertices.  
> **username_1**: Im fine with the other parts except is it a good idea. Since good is not well defined. This is not a convention thing as its merely a optimization problem, neither is clearly better in a context free situation. But we can not optimize in all possible contexts.  
> **username_0**: @username_1 Suppose we're animating 100000 vertices to randomly-chosen end points.  

---

## 1 answers

### Answer by username_1 on 2017-03-29. Score: 2

This is a pure optimisation problem. It depends on many factors like:

* What you need to do with the tween
* How many different tweens you need to calculate
* How much signaling between systems you need
* Whether you need to use that data in your CPU bound process or not.
* How much time you have to write the code
* What your tool set supports easiest
* ...

See if you only need one value to interpolate then your CPU is more than likely faster (unless you're running some weird embedded system). Even if you move a bunch of points you can still calculate the tween of that one position and do the needed cluster transformation in the GPU, like bone animation.

The GPU only starts to win against your processor if you need to calculate many truly separate animation curves in parallel. Or you're in an otherwise performance bound system like running JavaScript in a WebGL application. If you do use the GPU then it's most likely best to tween all vertices, at least unless your object is somehow massive. Since initiating a new draw call is costly and maintaining many states is more complex. Its just that those vertices that don't move would just move from starting point to starting point.

> **Comments:**
> **username_0**: I suppose I'd like to animate any numbers of particles to randomly chosen end points. It could be 100000 particles (where a particle could possibly have multiple vertices). It's a personal project for fun, so no time limit. I don't need the data on the CPU side, but I just need to know when the tween is complete on the CPU side.  

---

