Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Shader Trick

the-witness.net

Post reply on HN
Print view View original

31–40 of 56 posts

Re: A Shader Trick

#31

Post by zamadatix »

dataangel wrote: post #17
zamadatix wrote: post #16

Earlier quoted context omitted.

It doesn't have to be game time, as the article says it could be time since level or some other trigger. It's basically about any time based counter you need for a time based effect, such as a predefined cyclical wind effect on trees or waves in water. The article also explains why it has to be precise, looping effects will behave oddly if the loop is not occurring precisely. Splitting the number into a large part an…

If it moves the problem far enough forward in practice it won't matter though. If somebody runs The Witness for 100 days that's on them

It doesn't move it to 100 days, it'd move the problem to 10 minutes. Shaders can't just take a large number as a large piece and small piece unmodified, solving for this in the logic is the same as solving for the original cycle matching problem.

Re: A Shader Trick

#32

Post by jblow »

hwillis wrote: post #7
Scene_Cast2 wrote: post #5

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 wh…

> if you aren't precise to the millisecond things will jump around

It is correct that precision is very important here, but, a millisecond is way too coarse: at 120fps, a millisecond is 1/8 of the frame time, and you'd get horrible jitter.

Re: A Shader Trick

#33

Post by hwillis »

sgtnoodle wrote: post #21
Waterluvian wrote: post #12

The blog suggests that you need to use integers to describe time because floats have problems. Granted. Why limit one’s self to absolutely having to describe it in a single integer value? Why not some wrapper around a handful of integer values that can handle a much bigger max? Would this have a meaningful performance cost?

You could simply use a single 64 bit integer in, say, nanoseconds. That would give you 584 years of range. Just convert the integer into a float before passing it into the shader. For periodic effects, apply the appropriate modulo. Fog doesn't change very rapidly, so if wrapping is a pain, you could just accept the loss in precision. You could round the value as part of the conversion so that the precision doesn't ch…

> Just convert the integer into a float before passing it into the shader.

That solves no problems at all. The number needs to stay an integer until after it is fed to a periodic function, which will restore it to a small enough number to be precisely represented as a float.

> Fog doesn't change very rapidly, so if wrapping is a pain, you could just accept the loss in precision. You could round the value as part of the conversion so that the precision doesn't change over the range.

That doesn't help either. Unless you round the time uniform CPU side- sending a counter that is incremented once per second to the fog shader, and different counter incremented once per millisecond to the shimmer shader- you're still sending a giant number to a function that is periodic over a 1,000,000x smaller window. Precision errors will still cause wildly varying outputs.

Sending separate uniforms only solves the problem for very, very slowly varying functions.

> With 1 second precision, you should be good for a few months with a 32 bit float.

Human vision is exceptionally well-tuned for noticing sudden changes, even relatively subtle ones. A gradual change over 1 second can be hundreds of times larger than a sudden change before it's noticeable.

Re: A Shader Trick

#34

Post by hwillis »

jblow wrote: post #32
hwillis wrote: post #7

Earlier quoted context omitted.

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 wh…

> if you aren't precise to the millisecond things will jump around It is correct that precision is very important here, but, a millisecond is way too coarse: at 120fps, a millisecond is 1/8 of the frame time, and you'd get horrible jitter.

Ehh. The framerate doesn't actually matter that much, because in the end the actual pixel changes color at the same rate regardless of FPS. No shader is periodic at 120 Hz; they're very rarely periodic at even 10 Hz.

10 Hz is already a slow strobe light; 1 ms deltas means that each flash is within ~1% of the correct color.

If you're doing something like raymarching in the pixel shader, then you might want sub-millisecond resolution. In 99% of normal shaders, I don't think so. That kind of precision comes into play more with moving objects, where a tiny time delta can mean the difference between a pixel being completely lit or completely dark. Even then though, bad time resolution is just as likely to manifest as motion blur or something.

Re: A Shader Trick

#35

Post by jstanley »

I've been playing The Witness recently. I've enjoyed it a lot, and had a lot of "aha moments", but I wouldn't say I altogether understand the game. It has a very elusive nature. I'm working through (what I believe to be) the "ending" at the moment, but there is still a lot of the pre-ending stuff that I haven't figured out yet.

At first glance The Witness is a puzzle game, made annoying by the fact that you have to walk everywhere instead of clicking "Next Puzzle". But then you occasionally see things in the environment that are just really pleasing. An example that springs to mind is a bunch of broken metal in a window[0], and some branches on a tree, that line up with the sun (which doesn't move) to cast a shadow of a woman sitting underneath a tree[1].

And there's loads of this stuff. And noticing it doesn't contribute anything at all to the apparent objective of the game (except where it does!), but it adds so much that you just wouldn't get if it were the simple puzzle game that it initially appears to be.

I really like this game.

[0] https://img.incoherency.co.uk/3706

[1] https://img.incoherency.co.uk/3705

Re: A Shader Trick

#36

Post by nurbl »

jstanley wrote: post #35

I've been playing The Witness recently. I've enjoyed it a lot, and had a lot of "aha moments", but I wouldn't say I altogether understand the game. It has a very elusive nature. I'm working through (what I believe to be) the "ending" at the moment, but there is still a lot of the pre-ending stuff that I haven't figured out yet. At first glance The Witness is a puzzle game, made annoying by the fact that you have to w…

I think it's the game I've played that comes closest to feeling like a genuine mystery. Even though I think I've finished it, there are many aspects I still don't "get". It may just be that it's good at simulating this experience (sort of like a Lynch movie) but I don't think it matters. It's a great puzzle game wrapped in an enigma. And a piece of art too.

Re: A Shader Trick

#37

Post by lostmsu »

SquareWheel wrote: post #4
gfd wrote: 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 th…

Google for Minecraft Farlands took off half an hour of my life. Amazing floating-point-related bug.

Re: A Shader Trick

#38

Post by Etherlord87 »

hwillis wrote: post #30
Waterluvian wrote: post #12

The blog suggests that you need to use integers to describe time because floats have problems. Granted. Why limit one’s self to absolutely having to describe it in a single integer value? Why not some wrapper around a handful of integer values that can handle a much bigger max? Would this have a meaningful performance cost?

It doesn't suggest using integers. It suggests resetting your time uniform every 1000, 10000, 100000... etc. In values of ten raised to some (integer) power. The sole reason for picking a number like that is because programmers will tend to use constants like 32.768 instead of some fractional value. If you use 32.768 and reset your time uniform at 1000, the functions used with 32.768 will still loop seamlessly. Doubl…

> there's no reason for time to ever be much larger than 10000. One such reason would be a shader with an effect that is not trivial to loop.

For example, take a look at this looping technique: https://blender.stackexchange.com/a/195316/60486

Not only it isn't trivial, but also it requires a 4D texture. You may have a nice effect going on that uses a texture with less dimensions and looping it will be ever harder... Or ugly.

Re: A Shader Trick

#39

Post by initplus »

SquareWheel wrote: post #4
gfd wrote: 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 th…

Note these are seperate issues, caused by the same underlying issues with float precision.

Some game engines solve the jittery rendering issues by moving the world relative to the player/camera, rather than the opposite (though it may be more intuitive). This way all your shaders work in nice accurate low floats relative to the camera at the origin, no matter the player location in the world.

But to implement worldgen with relative coordinates would be much more complex.

Re: A Shader Trick

#40

Post by greggman3 »

jstanley wrote: post #35

I've been playing The Witness recently. I've enjoyed it a lot, and had a lot of "aha moments", but I wouldn't say I altogether understand the game. It has a very elusive nature. I'm working through (what I believe to be) the "ending" at the moment, but there is still a lot of the pre-ending stuff that I haven't figured out yet. At first glance The Witness is a puzzle game, made annoying by the fact that you have to w…

That game has a moment when you realize it's not quite about what you thought it was about. I hope this isn't a spoiler but there are black obelisks around the world. If you know what they are for then you've found this secondary goal
Post reply on HN