horizontally scale sin(ax) without adjusting anything inside those brackets.

[Cadellin]

Hi there. The following math is actually for a shader I'm working on. At the moment, the shader has three sine wave functions- one of period 25, one of period 20, and one of period 10, with the "period" being the interval it takes to form a full oscillation. I guess you could define those as sin(14.4x), sin(18x) and sin(36x).

The issue with that is that the sine function is a little expensive on the CPU compared to other functions. I would like to apply a transformation to one sine function, to derive the other two.
The conventional way of scaling a graph horizontally is of couse to change the value of A in sin(Ax), but in a coding context that would require me to do the sin operation three times to derive those three functions. Sounds like a minor thing, but when the operation gets applied to every single patch of water in an entire video game...

So effectively what I am looking for is a function outside of the sin operation, to derive the others like so:

FunctionA(sin(18x)) = sin(36x)
FunctionB(sin(18x)) = sin(14.4x)

Any ideas?

 

[ksdhart2]

One solution you might try is to implement a lookup table, like students used prior to calculators. If you pre-define sin(1), sin(2), ..., sin(360) as constants, you can then just look up those values as you need them. Like, let's say, x=1. Then you'd need to determine if there would be any noticeable graphical difference to the end user between using sin(14) and sin(14.4). If there is, then you'll want to find another solution. But if the slight loss of quality is acceptable, then you could simply fetch the value of sin(14) from your table of constants. Similarly, if x=4, grab sin(14x)=sin(56) from the table.

 

[Cadellin]

One solution you might try is to implement a lookup table, like students used prior to calculators. If you pre-define sin(1), sin(2), ..., sin(360) as constants, you can then just look up those values as you need them. Like, let's say, x=1. Then you'd need to determine if there would be any noticeable graphical difference to the end user between using sin(14) and sin(14.4). If there is, then you'll want to find another solution. But if the slight loss of quality is acceptable, then you could simply fetch the value of sin(14) from your table of constants. Similarly, if x=4, grab sin(14x)=sin(56) from the table.

Hmm, unfortunately I think it requires more than integer precision, as framerates will vary on players with different computers. That could cause jerking or variable speeds of movement using a lookup table. Good suggestion though.

 

[Harry_the_cat]

Hi there. The following math is actually for a shader I'm working on. At the moment, the shader has three sine wave functions- one of period 25, one of period 20, and one of period 10, with the "period" being the interval it takes to form a full oscillation. I guess you could define those as sin(14.4x), sin(18x) and sin(36x).

The issue with that is that the sine function is a little expensive on the CPU compared to other functions. I would like to apply a transformation to one sine function, to derive the other two.
The conventional way of scaling a graph horizontally is of couse to change the value of A in sin(Ax), but in a coding context that would require me to do the sin operation three times to derive those three functions. Sounds like a minor thing, but when the operation gets applied to every single patch of water in an entire video game...

So effectively what I am looking for is a function outside of the sin operation, to derive the others like so:

FunctionA(sin(18x)) = sin(36x)
FunctionB(sin(18x)) = sin(14.4x)

Any ideas?

The first one involves double angles.
Note that sin(2x) = 2 sinx cosx
So
sin(36x)= 2 sin(18x) cos(18x) could help.

Don't know about the second one though.