Reducing number of divisions for polygon mappers – part 4 March 29, 2008
Posted by winden in coding, demoscene.trackback
NOTE: moving to my new winden homepage
NOTE: moving to my new winden homepage
This site uses Akismet to reduce spam. Learn how your comment data is processed.
great!!! :)
btw… do you have RSS feed? :D
Yes, in fact all wordpress.com blogs include an RSS feed linked on the head of the page, so that firefox and safari can display a “subscribe to this page” icon:
link rel=”alternate” type=”application/rss+xml” title=”RSS 2.0″ href=”https://winden.wordpress.com/feed/”
Hi Winden,
Have you tried all this optimisation in a complete pipeline, i’m really curious about the precision.
Btw you can remove the division for the perspective gradient calculation
“instead of computing u/w and 1/w we’d be computing d*u/w and d/w. Per pixel we’re computing (d*u/w)/(d/w) = u”
Jamie
I can now see what you mean… both u/z and 1/z are traditionally scaled by the area of the polygon, so they cancel out when we divide them out. I guess that means perspective corrected mapping can be reduced to
Regarding the precision, I haven’t done any complete tests yet, but we should keep in mind that multiplying “generates” bits (32×32–>64) while dividing “kills” bits (64/32–>32), so it should be more precise than the usual way since all the calculations keep keep being done from the original bits and not from intermediate ones.
What is really interesting for me it’s that you can compute the gradient with no need to zclipp uv component, so you can clipp only on the x,y component.