TIL: lerp being A*(1-t)+B*t, if you lerp between the same value, say A=50 and B=50, you'll get a value that isn't 50, for some values of t. (floats) Kinda obvious in hindsight but surprised I never hit it before. I had to put in a special case for lerp. If (A==B) return A
-
-
Vastauksena käyttäjälle @Atrix256
I would make the argument that the base lerp function should assume a!=b, as a contract. You can assert in debug, but should impose no overhead in release. If users know their data could potentially violate this contract, they can check a==b themselves.
2 vastausta 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjälle @tloch14
Gotta hard disagree here. You are taking an implementation detail and making it everyone's problem. Everything is trade offs, so there are times when what you say is appropriate, but complicating all calls of lerp is a pretty big con, so not many imo.
1 vastaus 0 uudelleentwiittausta 2 tykkäystä -
And more context might be in order :) This is for non real time rendering, so this micro level perf isn't a big deal. The values come straight from data as well. I could check the data and do something about it, but would rather lerp just deal with it.
1 vastaus 0 uudelleentwiittausta 0 tykkäystä -
Vastauksena käyttäjälle @Atrix256
That’s the whole point. A core lerp() should not assume real-time or not. You, in your own application, can write a wrapper that makes some aggressive checks. Then you use that everywhere in your project.
1 vastaus 0 uudelleentwiittausta 1 tykkäys
At that point, you have the context to know what sort of trade offs can be made.
Lataaminen näyttää kestävän hetken.
Twitter saattaa olla ruuhkautunut tai ongelma on muuten hetkellinen. Yritä uudelleen tai käy Twitterin tilasivulla saadaksesi lisätietoja.