Jump to content
  • Advertisement
Sign in to follow this  
Promit

It's the Little Things That Matter -- Tips and Tricks

This topic is 4229 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I don't know about you guys, but I desperately need a break from the "How do I do XYZ" and "XYZ is broken plz help" threads. Not that they're a bad thing, but a change of pace is sorely needed. (Also, everyone posting threads in this forum uses the default post icon, or the question mark. How creepy is that?) Anyway, the point of this thread is to share small tips and tricks that we can all add to our graphics programming toolboxes. We're not talking big things here. Shadowing techniques and lighting models and all, those are big. This thread is for small, quick, compact things. I'll kick things off with a couple, and then hopefully lots of people will share more. Linearized Depth -- I'm sure most of you have run into that nasty problem where the Z buffer is actually exponential and so you get Z fighting artifacts if your far/near ratio is too big. Turns out there's a really nifty, easy hack that will turn your depth values back linear. The cost? One VS scalar multiply and two extra CPU divides when you set up your projection matrix. Two directional lights -- The linked project is absolutely beautiful thanks to several different tricks. But the most stunningly simple one is the application of not one but two directional lights for the outdoor lighting. I mean, most of us know to toss up a d-light to represent our sun and all, but adding a second one with a different color and angle adds a staggering amount of quality to the scene when done right. Premultiplied alpha -- Such a stupidly simple modification to standard alpha blending, yet you gain so much. I can't do the article justice; just read it and let Tom enlighten you.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
A word of caution: the "linearized depth" trick will only give you a linearized depth buffer if you only render screen-aligned polygons. The problem is that the division is done on interpolated values. lerp( n0 * d0, n1 * d1, f ) / lerp ( d0, d1, f ) != lerp( n0, n1, f ). This will introduce a new type of depth buffer artifact which may be more objectionable than the standard ones. It will be similar to the sort of artifacts you get when using linear interpolation while rendering dual paraboloid shadow maps. It could still be a precision victory, but the article should've mentioned this pitfall.

Share this post


Link to post
Share on other sites
This should also be a similar problem when doing perspective-correct texture mapping (or lighting, if you go that extreme). My guess is that the precision problems are not big enough to cause noticeable artifacts. And if you are doing perspective-correct texture mapping, you are already linearly interpolating 1/w, so your correct factor should be one vertex multiply or 3-4 scalars in G80.

Share this post


Link to post
Share on other sites
My current favorite "tip" is that time spent doing proper rendering debug aids is invaluable. I recently added a little debug thing which overlays the contents of render-to-texture buffers and it's been really helpful while developing some of the neat effects I've been messing with. Without it you end up doing quick debug hacks and trying to render the immediate outputs to the framebuffer which always gets messy and error prone.

Tip #2: Making it possible to reload a shader while an app is running saves you wasting lots of time waiting for the app to start up each time, and means you get better quality results.

[Edited by - OrangyTang on December 15, 2006 7:26:33 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
A word of caution: the "linearized depth" trick will only give you a linearized depth buffer if you only render screen-aligned polygons. The problem is that the division is done on interpolated values. lerp( n0 * d0, n1 * d1, f ) / lerp ( d0, d1, f ) != lerp( n0, n1, f ). This will introduce a new type of depth buffer artifact which may be more objectionable than the standard ones. It will be similar to the sort of artifacts you get when using linear interpolation while rendering dual paraboloid shadow maps. It could still be a precision victory, but the article should've mentioned this pitfall.


A little aside to Promit and reltham:



Although, like you guys mentioned in IRC last night, a little more detail about this artifact would be nice. Where/how does it come up? How does it exhibit itself, etc?

Share this post


Link to post
Share on other sites
OMG Why havent I ever heard of premultiplied alpha?!
How can people forget such a neat technique?
I will tell everyone I know to use it...

Share this post


Link to post
Share on other sites
Quote:
Original post by Cypher19
Quote:
Original post by Anonymous Poster
A word of caution: the "linearized depth" trick will only give you a linearized depth buffer if you only render screen-aligned polygons. The problem is that the division is done on interpolated values. lerp( n0 * d0, n1 * d1, f ) / lerp ( d0, d1, f ) != lerp( n0, n1, f ). This will introduce a new type of depth buffer artifact which may be more objectionable than the standard ones. It will be similar to the sort of artifacts you get when using linear interpolation while rendering dual paraboloid shadow maps. It could still be a precision victory, but the article should've mentioned this pitfall.


A little aside to Promit and reltham:



Although, like you guys mentioned in IRC last night, a little more detail about this artifact would be nice. Where/how does it come up? How does it exhibit itself, etc?


Looking at the dual parabloid shadow map problem discussing in this paper: http://portal.acm.org/citation.cfm?id=1183316.1183331&coll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184618
I think that as long as everything uses the linearized Z approach then it will all distort in the same way and work as desired for Z buffer usage. Since we aren't visualizing the Z, we are just using it for relative comparisons, I think it won't really matter.

Of course, I could be wrong, we'll need to do some detailed testing.

Share this post


Link to post
Share on other sites
Wow, someone has actually seen/read our paper! =) Anyways, I'm curious to hear about any related results. The depth buffer is such a tricky beast. Although I'd have to go look at the linearized Z stuff in more detail to see how related it is to the DPSM stuff.

Share this post


Link to post
Share on other sites
Premultiplied Alpha FTW! I typically use it for my particle systems, so that the same texture can both make things darker (high alpha, low brightness), brighter (low alpha, high brightness) or blended (medium alpha, medium brightness).

Linear depth buffers are actually a bad idea. With the regular Z buffer, the shape of a pixel is isomorphic across the range of the scene. With a linear Z buffer (a k a a W buffer), the shape of a pixel is very deep and skinny up front, and very wide and stubby out towards the end.
Another way to think about it: If a pixel covers 1x1 centimeter 2 meters from the viewer, and covers a 0.1 cm depth area in the Z buffer, it should be 2x2 centimeters when it's 4 meters from the viewer, and cover a 0.2 cm range in Z. With linear buffers, the same pixel will likely cover 1x1x1 cm at 2 meters, and 2x2x1 cm at 4 meters.

Share this post


Link to post
Share on other sites
Quote:
Original post by Promit
Premultiplied alpha -- Such a stupidly simple modification to standard alpha blending, yet you gain so much. I can't do the article justice; just read it and let Tom enlighten you.


Just something to note for people who want to implement this: Make sure you also multiply the vertex color by the vertex alpha, otherwise you'll get all sorts of wacky effect when you try to fade out your particles. :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!