Jump to content

  • Log In with Google      Sign In   
  • Create Account

How to mipmap procedural shaders?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Wessam Bahnassi   Members   -  Reputation: 164

Like
1Likes
Like

Posted 18 November 2013 - 11:45 AM

A general observation for shaders that rely on procedural functions f(u,v) to generate colors is that such shaders may alias so hard at the distance. For example, if f(u,v) generates periodic lines on u and v then on distant surfaces those lines alias strongly (see attachment). If we replace the procedural function with a mipmapped texture lookup then the result improves a lot.

So my question is, is there a generic way to make a function f(u,v) "mipmap" in a pixel shader aside from the texture approach?

 

 

Attached Thumbnails

  • shaderAliasing.png


Sponsor:

#2 NickW   Members   -  Reputation: 313

Like
1Likes
Like

Posted 18 November 2013 - 03:29 PM

What you want is actually anti-aliasing since what you're making is closer to rasterizing than texture mapping.  You can use any of the anti-aliasing techniques that people have been using for years, such as multisampling. You'll just have to implement them in your fragment shader, and depending on how it's written, could be very tricky.

 

Think of each pixel as a tiny little frustum instead of a ray.



#3 Wessam Bahnassi   Members   -  Reputation: 164

Like
0Likes
Like

Posted 18 November 2013 - 05:18 PM

What you want is actually anti-aliasing since what you're making is closer to rasterizing than texture mapping.  You can use any of the anti-aliasing techniques that people have been using for years, such as multisampling. You'll just have to implement them in your fragment shader, and depending on how it's written, could be very tricky.

 

Anti-aliasing in terms of today's APIs works on geometry edges not on shading.

 

 

Think of each pixel as a tiny little frustum instead of a ray.

 

Yup, that's closer to a sensible approach. du/dv tells you the frequency you're being sampled at... so theoretically you do "multisampling" at higher frequencies and average the results. But I want to know if anyone has smarter/faster ideas than this...



#4 kalle_h   Members   -  Reputation: 1566

Like
2Likes
Like

Posted 19 November 2013 - 04:17 PM

Iquilezles have nice filtering shader there. https://www.shadertoy.com/view/MdjGR1



#5 mikiex   Members   -  Reputation: 244

Like
0Likes
Like

Posted 20 November 2013 - 04:28 AM

not so generic but for lines would be to measure the ddx ddy much like the classic checkboard shader



#6 LorenzoGatti   Crossbones+   -  Reputation: 2763

Like
0Likes
Like

Posted 21 November 2013 - 04:14 AM

 


What you want is actually anti-aliasing since what you're making is closer to rasterizing than texture mapping.  You can use any of the anti-aliasing techniques that people have been using for years, such as multisampling. You'll just have to implement them in your fragment shader, and depending on how it's written, could be very tricky.

 
Anti-aliasing in terms of today's APIs works on geometry edges not on shading.
 
 

Think of each pixel as a tiny little frustum instead of a ray.

 
Yup, that's closer to a sensible approach. du/dv tells you the frequency you're being sampled at... so theoretically you do "multisampling" at higher frequencies and average the results. But I want to know if anyone has smarter/faster ideas than this...
You need to take care of antialiasing in each fragment, which means calling a "smart" antialiasing-aware fragment shader instead of a naive one. Your shader can be less costly than brute-force pure multisampling; for example, it can generalize and abuse texture mipmapping for your specific needs (more lowpass filtering for increasing fragment depth).

The only possible way to get cheaper but lower quality antialiasing is cheating with intermediate frame buffers: scaling up a properly antialiased small buffer (saving a lot of shader invocations) or fixing the ugly results of your original shader with "morphological antialiasing" or similar postprocessing.
Produci, consuma, crepa

#7 Krohm   Crossbones+   -  Reputation: 3245

Like
0Likes
Like

Posted 25 November 2013 - 02:18 AM

For this specific example I would probably write an ad-hoc shader numerically evaluating coverage.

 

The above link looks extremely interesting, I will have to look at it in more detail.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS