Time uniform accuracy. about shadereditor HOT 22 CLOSED

Well, yes, probably. I used a float because the time almost certainly ends up in a calculation with floats anyway and this way there is no further conversation necessary.

On the other hand, the GPU will probably auto convert ints into floats so that may not make much of a difference. I will have to make some tests to see if there are any side effects from using an int; especially on bad/old hardware. Don't want to break anything here.

Of course, another way to avoid accuracy problems would be to use high precision floats:

precision highp float;

from shadereditor.

You don't have to remove the old uniform, just add a new one. The problem is that high precision floats are slower, and smartphones aren't very powerful... With an integer you can trim the integer value before converting it into a float, so you don't lose accuracy.

from shadereditor.

That's right, of course. I'd just prefer to not having two time uniforms when one would do. So if it doesn't have any side effects, I'll convert the existing one, but if it does, I'll simply add a new one like you suggested.

And, indeed, highp can be anything from unavailable to low performance on smartphones, unfortunately. At least, it slowly gets better with new devices I think.

from shadereditor.

Oh, and highp doesn't solve the problem because the time data is converted to float before calling the shader, so the most you can get is 32 bit accuracy, right?

from shadereditor.

Well, that depends on the problem. highp does solve some precision problems on some devices.

But in general, you're right, the time is converted to a 32 bit float before handing it to the shader.

from shadereditor.

Hi!
I think I have the same issue but I'm not sure.
Over time, the time variable become slower and slower but the number of FPS is still the same and the UI and the touch are not affected.
If I lock and unlock my phone, it reset the problem so the time variable is fast again but it is still getting slower and slower over time.

Hope it helps!
( Awesome app to learn GLSL by the way ;) )

Edit: My phone is a Samsung Galaxy note 2 (gt-n7100)

from shadereditor.

Very strange. Honestly I don't have an idea yet what's causing this but it's certainly interesting. Thanks a lot for reporting!

from shadereditor.

It could be the same issue. When the value of the variable is big the increments are less noticeable so it may result in that kind of behaviour.

from shadereditor.

Yes, you're right, of course! Really hope I can do an update very soon. That really needs to be fixed.

from shadereditor.

Yeah, it's a shame that this problem is there because the rest of the program is really good. This one and the other active issue of not knowing when the screen is pressed or not.

from shadereditor.

Hello again !
The issue doesn't seem to come from your app!!!
I'm programming fragment shaders in GLSL with LibGDX and I have exactly the same issue on android.
LibGDX is a multi-platform library in java, and when running the shader on PC it works fine. The issue only appear on android.

Tested on my two android devices : Samsung Galaxy note 2 (gt-n7100), and Archos GamePad 2.

from shadereditor.

Hi, I think I found a solution for this. Check this commit.

The root problem is a GLSL float is not very long (especially with mediump) and you get very quickly rounding errors with large numbers.

So I simply wrap time before the rounding errors get noticeable. What should be perfectly okay because time is basically nothing but a marker for where you are in an repeating animation.

from shadereditor.

Hi!
I was thinking about this time problem and I think the best solution would
be to send an integer and a float to the shader, the integer representing
the seconds and the float the fractional part of a second. This way anyone
could wrap themself the time and it wont create a gap in animation. Also
you could then just add the two values together to get the actual time
value.
On 17 Aug 2015 12:00, "Markus Fisch" [email protected] wrote:

Hi, I think I found a solution for this. Check this commit
0056b93
.

The root problem is a GLSL float is not very long (especially with
mediump) and you get very quickly rounding errors
http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html#680 with
large numbers.

So I simply wrap time before the rounding errors get noticeable. What
should be perfectly okay because time is basically nothing but a marker
for where you are in an repeating animation.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

from shadereditor.

No, this wouldn't work.

First, according to the specification, a mediump int has a range from -2^10 to 2^10 (-1024 to 1024). What means it would wrap just after a second.

And mediump is still important since the app should also run on low end devices.

Then, if we'd use an int, we would almost certainly have to cast it in the shader what is at least an unnecessary inconvenience.

from shadereditor.

You're right, sorry. I wasn't aware of the precision specifiers'
specifications.
But a wrap will still create a jump in animation, so the one that creates
the shader should be aware of the limitations of his device and overcome
them by wrapping the values themselves.
On 17 Aug 2015 21:43, "Markus Fisch" [email protected] wrote:

No, this wouldn't work.

First, according to the specification
https://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf,
a mediump int has a range from -2^10 to 2^10 (-1024 to 1024). What means it
would wrap just after a second.

And mediump is still important since the app should also run on low end
devices.

Then, if we'd use an int, we would almost certainly have to cast it in the
shader what is at least an unnecessary inconvenience.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

from shadereditor.

Well, that would make exchanging shaders between devices even more problematic. And it would raise the bar for newcomers as they would have to deal with the hardware limitations of their device first.

So, in my opinion, a well-known, pre-defined limit is probably better. Only that it's not well-known at the moment :) The app really needs a little documentation - within the app - about all available uniforms and their limitations I think.

Would you consider 65535 to be a fair choice for everyone or would you rather choose to have a configurable preference for that? A preference would affect exchangeability, of course, but one would have more freedom.

from shadereditor.

Yeah I guess 18 hours of time would be enough ;)
On 18 Aug 2015 13:53, "Markus Fisch" [email protected] wrote:

Well, that would make exchanging shaders between devices even more
problematic. And it would raise the bar for newcomers as they would have to
deal with the hardware limitations of their device first.

So, in my opinion, a well-known, pre-defined limit is probably better.
Only that it's not well-known at the moment :) The app really needs a
little documentation - within the app - about all available uniforms and
their limitations I think.

Would you consider 65535 to be a fair choice for everyone or would you
rather choose to have a configurable preference for that? A preference
would affect exchangeability, of course, but one would have more freedom.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

from shadereditor.

No, time is in milliseconds, so 65535 is just over a minute.

The thing is, a mediump float is only 10 bits long too.

from shadereditor.

As suggested above a second variable could count the minutes passed and
time would then wrap around the minute.
On 18 Aug 2015 18:39, "Markus Fisch" [email protected] wrote:

No, time is in milliseconds, so 65535 is just over a minute.

The thing is, a mediump float is only 10 bits
https://www.khronos.org/files/opengles_shading_language.pdf long too.

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

from shadereditor.

I'm an idiot. time is not in milliseconds but seconds. So 65535 is indeed well over 18 hours.

Fixed in version > 2.

from shadereditor.

Shaders are looking silky smooth after this update.

from shadereditor.

Time is in seconds but you usually need milisecond accuracy for the animation to be smooth, so you need all decimal bits up to a milisecond to be accurate.

from shadereditor.