3 ms·

Ah. I think you're talking about something completely different from what jblow and I were talking about. If you mean that the code in the article is not optimi

by psyc 10y ago

Ah. I think you're talking about something completely different from what jblow and I were talking about. If you mean that the code in the article is not optimized, and is doing crippling amounts of redundant computation, then of course I agree with you.

pandaman 10y ago
The guy asked what kind of magic is calling trig functions in inner loops? I replied that nobody really did it and I am confused as to what the author was trying to show. I, frankly, do not understand what you and jblow read into this other than what I said.
- jblow 10y ago
  Hahaha, I guess it's a big misunderstanding. You wrote: "Nobody really wrote software rendering like that beyond CG classes". I read this as a claim that nobody in general wrote software renderers. When by "like that" you just meant using the specific techniques he used. That said, I still have to disagree, in the sense that, to get to a fast software renderer, you start with a slow software renderer. Nobody does all the crazy optimizations a priori ... so stuff like a divide per pixel was common, say. Calling trig functions in inner loops is of course goofy, but my presumption is that in the next step of refinement those would be lifted out of the loops, because that is the way things are always done.
  - pandaman 10y ago
    As I said, it's bad as a tutorial: It enforces the stupid idea, that you rasterize 2D triangles for a 3D renderer. People, who think this way are then completely shocked and mystified as to why there is perspective distortion to the surface attributes. And then, on 2D triangles, it enforces a bizarre notion that a triangle is not flat, so the surface attributes gradients can change from scanline to scanline.
  - tripzilch 10y ago
    > Nobody does all the crazy optimizations a priori ... so stuff like a divide per pixel was common, say. Calling trig functions in inner loops is of course goofy, but my presumption is that in the next step of refinement those would be lifted out of the loops, because that is the way things are always done. Yeah, .. but no. Depends on what era you're talking about I guess. When I wrote my first low-level rasterizer + basic 3D poly engine-ish-thing in 1998, I honestly wouldn't have considered for a second to do a division per scanline. An integer add was one tick, a mul was 3-10 (iirc), but a division was 10-40 ticks. Depending on what point you start considering the optimizatons "crazy", yes, had I known (and cared) about perspective correct shading back then, I would have started designing the algorithm, a priori (which for me usually meant on grid-paper) hunting for some way of faking a sufficiently accurate reciprocal using adds, shifts and at most 2 muls (per scanline, cause per pixel even a single mul was madness, obviously). With what I knew back then, probably go for a 2nd degree polynomial that might be sufficient to at least give the impression it was doing better than naive bilinear? :) Had I been aware of Carmack's (objectively crazy) inverse sqrt hack, I would probably have started looking in that direction (abusing the IEEE float spec on the bit level woohooooo). Sure you could write a perspective correct triangle rasteriser with a div per scanline, and it would be too slow, it would be a nice theoretical proof of concept, but it would also be kinda useless if it turned out you couldn't make the above crazy hacks run fast enough. They were a real hurdle that had to be crossed or you might as well not bother. Also, why save the fun stuff for last? ;-)

by psyc 10y ago

pandaman 10y ago

The guy asked what kind of magic is calling trig functions in inner loops? I replied that nobody really did it and I am confused as to what the author was trying to show. I, frankly, do not understand what you and jblow read into this other than what I said.

jblow 10y ago
Hahaha, I guess it's a big misunderstanding. You wrote: "Nobody really wrote software rendering like that beyond CG classes". I read this as a claim that nobody in general wrote software renderers. When by "like that" you just meant using the specific techniques he used. That said, I still have to disagree, in the sense that, to get to a fast software renderer, you start with a slow software renderer. Nobody does all the crazy optimizations a priori ... so stuff like a divide per pixel was common, say. Calling trig functions in inner loops is of course goofy, but my presumption is that in the next step of refinement those would be lifted out of the loops, because that is the way things are always done.
- pandaman 10y ago
  As I said, it's bad as a tutorial: It enforces the stupid idea, that you rasterize 2D triangles for a 3D renderer. People, who think this way are then completely shocked and mystified as to why there is perspective distortion to the surface attributes. And then, on 2D triangles, it enforces a bizarre notion that a triangle is not flat, so the surface attributes gradients can change from scanline to scanline.
- tripzilch 10y ago
  > Nobody does all the crazy optimizations a priori ... so stuff like a divide per pixel was common, say. Calling trig functions in inner loops is of course goofy, but my presumption is that in the next step of refinement those would be lifted out of the loops, because that is the way things are always done. Yeah, .. but no. Depends on what era you're talking about I guess. When I wrote my first low-level rasterizer + basic 3D poly engine-ish-thing in 1998, I honestly wouldn't have considered for a second to do a division per scanline. An integer add was one tick, a mul was 3-10 (iirc), but a division was 10-40 ticks. Depending on what point you start considering the optimizatons "crazy", yes, had I known (and cared) about perspective correct shading back then, I would have started designing the algorithm, a priori (which for me usually meant on grid-paper) hunting for some way of faking a sufficiently accurate reciprocal using adds, shifts and at most 2 muls (per scanline, cause per pixel even a single mul was madness, obviously). With what I knew back then, probably go for a 2nd degree polynomial that might be sufficient to at least give the impression it was doing better than naive bilinear? :) Had I been aware of Carmack's (objectively crazy) inverse sqrt hack, I would probably have started looking in that direction (abusing the IEEE float spec on the bit level woohooooo). Sure you could write a perspective correct triangle rasteriser with a div per scanline, and it would be too slow, it would be a nice theoretical proof of concept, but it would also be kinda useless if it turned out you couldn't make the above crazy hacks run fast enough. They were a real hurdle that had to be crossed or you might as well not bother. Also, why save the fun stuff for last? ;-)