2
$\begingroup$

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?

$\endgroup$
4
  • $\begingroup$ Please dont ask for oppinions. They dont give out clear answers. Yes, it works. $\endgroup$
    – joojaa
    Mar 28 '17 at 5:05
  • $\begingroup$ @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. $\endgroup$
    – trusktr
    Mar 28 '17 at 17:55
  • $\begingroup$ 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. $\endgroup$
    – joojaa
    Mar 28 '17 at 18:33
  • $\begingroup$ @joojaa Suppose we're animating 100000 vertices to randomly-chosen end points. $\endgroup$
    – trusktr
    Apr 4 '17 at 23:15
2
$\begingroup$

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.

$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – trusktr
    Apr 4 '17 at 23:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.