Live data from Hacker News

A Shader Trick

the-witness.net

1–10 of 56 posts

Re: A Shader Trick

#3
post #2

I think I've read that minecraft behaves differently depending on how far away you are standing from the origin for similar reasons: [1] https://minecraft.fandom.com/wiki/Bedrock_Edition_distance_e... [2] https://minecraft.fandom.com/wiki/Java_Edition_distance_effe...

In Roblox this happens if you get thrown too far: https://www.youtube.com/watch?v=Fw1GZLodmtw

Re: A Shader Trick

#4
post #2

I think I've read that minecraft behaves differently depending on how far away you are standing from the origin for similar reasons: [1] https://minecraft.fandom.com/wiki/Bedrock_Edition_distance_e... [2] https://minecraft.fandom.com/wiki/Java_Edition_distance_effe...

Yes, the Minecraft Farlands are caused by precision issues of floating point numbers. The game becomes jittery as it tries snapping to fewer and fewer precise digits. This is most obvious at first in the selection box around blocks, but the terrain also becomes unstable after a certain point.

Note that one Youtuber KurtJMac has been walking to the Farlands since 2011. He's been raising money for charity as part of those videos/streams. He's roughly 40% of the way there.

https://www.farlandsorbust.com/

https://www.youtube.com/user/kurtjmac

Re: A Shader Trick

#6
Aha! This explains a 20-year-old mystery bug! In undergrad, one of my side projects was a procedural 3D world from scratch (kind of Myst meets Halo), including physics, graphics (OpenGL), and the raw synthesized sound of ocean waves and plasma grenade explosions from sine waves via granular synthesis. After about 10 minutes exploring the world (or running around throwing tiny spheres down hills and scattering them with plasma grenades) my relaxing synthesized ocean wave sounds started to sound garbled and distorted so I always had to restart the program — now I know why :)

Re: A Shader Trick

#7

Could you use a non-float integer instead? Do GPUs have cheap int % float -> float operations?

1. Integers would make the situation easier, but still overflow after ~50 days. You can't just increment delta every frame; frame times vary significantly and and if you aren't precise to the millisecond things will jump around.

2. It's not exactly cheap, and I don't think compilers put much effort into making sure you actually retain that precision. I have only really used floats in shaders though, and don't know what would happen.

3. I'm pretty sure that in practice you'd lose out on a lot of hardware-accelerated functions, doing trig and interpolations with multiple messy conversions. It's also possible you'd fuck up some compiler optimizations.

Re: A Shader Trick

#8

Could you use a non-float integer instead? Do GPUs have cheap int % float -> float operations?

int % float -> float is not a native operation I'm aware of on any CPU or GPU. Even C doesn't have this operation -- the % operator only applies to integers, and the float variant is a function, fmodf(float, float); shading languages are similar. Also note that GPUs don't have any sort of integer division instruction.

Re: A Shader Trick

#9
post #2

I think I've read that minecraft behaves differently depending on how far away you are standing from the origin for similar reasons: [1] https://minecraft.fandom.com/wiki/Bedrock_Edition_distance_e... [2] https://minecraft.fandom.com/wiki/Java_Edition_distance_effe...

I believe that every game have this problem if you are far enough away from the origin. 3kliksphilip did a great video on this subject: https://www.youtube.com/watch?v=eK7eNgiQfhk

Re: A Shader Trick

#10
I think that instead of this, my solution would be to have each function that depends on dt to accumulate the dt themselves, and reset it at their individual periods.

A Rust trait with an associated const would help with this:

    trait TimeDependentFn {
        const PERIOD: f32;
        type Output;
    
        fn call(&self, dt: f32) -> Self::Output;
    }
Post reply on HN