9 ms·
Rational rendering and floating bar
- Flow 8y agoVery cool article but the scroll-jacking makes this painful to read on an iPhone. :-(
- deleted 8y ago[deleted]
- nimish 8y agoI was hoping the author went full circle to reinventing floating point, but this is a great writeup of the process. Really good motivation.
- tomxor 8y agoRe-inventing floating point format would be missing the point (edit: i honestly did not see that pun sorry).. floating point formats cannot represent all of the rational numbers that a fraction could using the equivalent bits e.g 1/10 can be represented in base 10 decimals but not in base 2 float (where it has a repeating significand much like 1/3 in base 10), which becomes a problem when doing further math on it, try: 1/10 + 2/10). Both methods result in "holes" bellow zero (necessarily of course), but they do not fit inside each other. However within a limited set of operations, rational numbers (within a capable format, and with necessary operators) have some interesting properties over floating point math that makes them desirable, i.e not loosing precision (unless overflow due to encountering large primes), and they are less expensive (built on integer math). What he did do, is make a rational number bit format (floating bar) which stores everything as fractions, it's quite elegant really and anyone familiar with IEEE754 will see the similarities.
- Veedrac 8y agoFloating point is also built on integer math, and cheaper operations at that.
- tomxor 8y agoUltimately yes, but I'd be interested in a side by side comparison, without FPUs. Also as explained in the article, divide (which is expensive float operation) is as cheap as integer multiplies with fractions.
- Veedrac 8y agoIt's very rare not to need GCD reduction, though; multiplying values burns through bits extremely fast. Only doing factor-2 reduction isn't infeasible but you'd be further damaging an already iffy type.
- theoh 8y agoThere are rational geometry libraries which are precise (edit: I mean that answers are "exact"): http://www.algorithmic-solutions.info/leda_guide/Geometry.html http://www.algorithmic-solutions.info/leda_guide/Geometry.ht... Quilez's concern with how the number fits into 32 or 64 bits may be necessary for performance, but using arbitrary precision numerators and denominators is the only way to achieve the robustness he was initially pursuing.
- deleted 8y ago[deleted]
- twic 8y ago> Exceptions to the rule of "operations on rational number produce rational numbers" are the square roots and the trigonometric/transcendental functions. For the later, I always express my opinion that if you find yourself doing trigonometry in the geometrical internals of your renderer, you are most probably doing things wrong Is that because you can express a rotation (etc) as a matrix? If so, don't you need to be able to do the trigonometry exactly to create a correct rational matrix in the first place? What am i missing? Or is it that you just don't need to do those sorts of operations at all inside the renderer?
- jmts 8y agoI assume (though I'm certainly not as knowledgeable as Inigo) that he's suggesting most functionality that uses trigonometry during rendering in some way tends to be performed using dot- and cross-products - which are calculated using only basic arithmetic operations - and therefore don't require slow mathematical function calls. If the actual value of a cosine is needed in some way, it will likely be calculated via the dot-product of two vectors, where one or both has unit length. As far as construction of rotation matrices goes, most of that will be baked before rendering a frame, so expensive trigonometric calculations and their conversion to rationals will occur ahead of time and therefore much less frequently than anything done per pixel, improving performance. In computer graphics, because a great many calculations need to be done for each pixel to be displayed, use of expensive functions tends to be avoided. In the literature I recall reading a number of triangle-ray intersection algorithms where each breaks down precisely how many adds, multiplies, divisions, etc are performed because the goal is to minimize all these things. If you are intersecting 10 triangles per pixel at 2 million pixels per frame, a single multiply per intersection becomes 20 million multiplies per frame. By contrast, recalculating the camera matrix using expensive functions should only happen once per frame.
- jacobolus 8y agoEveryone should use vector methods and shy away from transcendental functions to the extent possible. It is usually (but not always) possible to reframe problems in such a way that exponentials (including sine/cosine/tangent) and logarithms (including arcsine, arctangent, ..) are unnecessary. Vector methods are much faster, have fewer weird edge cases, are less subject to rounding error, etc. As an example: if you want to store a planar vector, use a pair of coordinates instead of an angle measure and magnitude. If you want to store an 2d orientation or rotation, still use a pair of (x, y) coordinates on the unit circle instead of angle measure (which is a logarithmic quantity). If you want to reduce your pair of coordinates to a single number, use the stereographic projection, which only requires division.
- erikpukinskis 8y agoInigo is a pioneer living decades ahead of the field. Utterly futuristic approach to graphics.