Not sure if this is a bug in 2.92, but it is weird. I spotted this while playing with a roundcube made as a quadshere, (although I doubt the nature of the mesh is important). If you add a wave modifier and offset the time to start by a minus figure, (even a large one), everything is shifted in phase as you would expect. However if you add a keyframe to the width value for frame 1 and a different value for a later frame, and then offset the time to a considerable negative degree, (e.g. -10000), you see some very weird effects, (rapid trembling or ultra slow movements). I haven't worked out exactly what time offset value prompts this, or its relationship to the render time, but more modest values give no problem. I think it's just the width parameter that prompts all this. Keyframing the height doesn't prompt it. I guess it's a curiosity rather than a big deal as using modest values is just fine, but maybe there are other consequences coding wise?
jjimcoote not entirely sure what you mean.
Check Wave Modifier - Blender Manual for a better understanding.
The time offset is basically moving the wave cycle back or forward in time (in frames). An offset of -10000 doesn't make sense. 10000 frames at 24fps is over an hour, why would you do that? The point of the offset is so the wave is already in motion when the animation starts. From my testing a typical wave is around 12 frames, so a value more than this is almost pointless. I don't think it is a bug, just obscure values that cause the issue.
Hi Adrian, sometimes I've used very slow wave movements, (these seem compatible with certain height / width/narrowness combinations), so I've benefited from having patterns appear at full size from frame 1 by offsetting by minus 50-100. I guess that has prompted a habit of just picking a large number just to be sure. That's the only reason I spotted this. I suggested -10000 just to make sure people saw what I meant. I agree that it's not a big issue as it's easy to avoid. I raised the point in case this had consequences for how Blender code is built. I have zero Python skills and have no idea of how interconnected the code behind Blender is. I guess 'bug' depends on your definition, but I presumed they are sometimes best spotted by deliberate exaggeration.
I guess 'bug' depends on your definition, but I presumed they are sometimes best spotted by deliberate exaggeration.
In math I'd agree with you jjimcoote but we are using computers here and they have a limited size for storing numbers, meaning that a real numbers has to be represented in a computer by a rounded version (usually called a Float) of itself.
And considering a 'space' of around 100000 Frames, means that 1 Frame has a lot less accuracy, than when you have 1000 Frames.
I don't know what exactly is causing the glitches, but I guess it is because of rounding errors.
Like when you put Suzanne far away from 'home':
It's like you would expect there to be a limit on the value. Trouble is what is the limit? Everyone is going to create different waves and need different values. You can get funky result with a lot of things in Blender, Its all about getting the right value for your needs.
That's interesting about the 'float' Spikey, I hadn't thought of that. Interesting that it only happens with the Width parameter, and that it's provoked by keyframing. It seems to cut in around the minus 500 -1000 frame mark. I was more concerned about whether similar phenomena would become manifest for any parameter linked to that particular code, (or similar parameters that can be keyframed). To the Python illiterate like me, it's easy to imagine that happening as Geometry nodes etc take Blender into more complex territory.
Interesting that it only happens with the Width parameter
well, that is to be expected, as the width is measured on the 'X-axis', which is the axis that time (Frame) is measured on...
Like wavelength (width) is connected to frequency through time..
The height is just the amplitude of a wave and that is independent of time (or frequency)...
(In reality (acoustics), this is not entirely correct (because there are multiple waves interacting), but in computer simulations like this, with a simple wave,this simplification works.)
Thanks Spikey, I see more deeply now. It sounds like any issue is likely to be confined to a narrow range of selections that I happen to have stumbled upon.