float currU = 0.01f * localTime;
newhorizonTex.y = tex0.y + currU;
newhorizonTex.x = tex0.x - currU;

The animation initially works for the first few steps, then the texture gradually gets distorted.. and sucked into the pinch of the mesh..
thanks
Jack

Maybe precision goes down with growing numbers? You could prevent this by using only the fractional part of the number (meaning newhorizonTex.y -= floor(newhorizonTex.y) ).

This method works great but still when local time becomes very large... the range I allow for the localtime is just 0-86400

so when the localtime is about 0, there is no artifact whatsoever, when I use the time, namely the morning, and the value is 21400..

then the texture starts to break...

should I first calculate the maximum u that I can shift first, and work backwards?

and is the reason bad texturing? and the texture should be tilable, not sure, because when baking the polar map, is it also needed to use a tilable texture?

thanks

Jack

So your period is one day and one unit is one second.

Over the thumb we can say single precision float stores 6 digits. So for a number like 80000 it is expected the fraction of a second can no longer be represented with goo accuracy.

(You can use this to find out: http://en.cppreference.com/w/cpp/numeric/math/nextafter)

There are multiple ways to fix this:

* Use double to store time, but be careful to keep precision when converting it to float, e.g. like so:

double scroll_period_in_seconds = 10;

double x = MyTimeOfDayInSeconds(); // be sure to convert system value directly to double, not using floats 

x /= scroll_period_in_seconds;

x -= floor(x); // values 0...1 over period of 10 seconds

float texture_U = vertex_u + float(x); // only finally convert to single precision

* Use a smaller period like one minute instead one day. Results in storing multiple variables for time with various periods, suiting various needs in precision.

* Using integer instead floating point can help too, or even combining both, like using integer for minutes and float for the fraction of the current minute.

System time is usually given in 64 bit integer, you could use just that - would be more accurate than conversion to double.

* Build your own floating point lib in software, which is able to use a variable number of bits,  haha (some people really need to do this)