Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Jul 2006
Offline Last Active Sep 13 2013 05:52 PM

Posts I've Made

In Topic: GL_FRAGMENT_SHADER_DERIVATIVE_HINT Is this useful anymore?

18 July 2013 - 02:43 AM

Back to the point, this kind of inter-pixel communication is only possible with "high quality" derivatives. With "low quality" derivatives, only 3 out of every 4 pixels can communicate, with 1 out of 4 pixels being isolated and unable to talk to the others in it's "2x2 quad".


Wow.   Ok.   Yes, this is was I was after.  :)

Acknowledgement that there actually _are_ different levels of derivative "quality" on modern hardware.


I help author a high-end tool which runs on the most modern of cards.  We're very quality concious ( rather than speed ).

So I'm going to set this hint to HighQuality regardless in our app from now on.



I know derivatives are used to select mip-map levels during texturing.

Do you know what happens if a polygon occupies only 1 pixel on screen?   ( or even 2x1 )

Any idea what the derivatives will give in that scenario?  And what mip-map level will be chosen?




In Topic: Procedural planets - floating point precision handling

24 February 2012 - 02:49 PM

Hi there

Your idea of translating everything to the 0,0,0 point seems fine
Its the method I've used before. ( and other packages I've worked on )

We stored our planet geometry in the CPU in worldspace doubles. ( it was an old project )
Then converted all the double-precision data to a 32bit camera=0,0,0 positioning scheme before sending to the card.

But if you're doing it using the compute shader then yea... I guess convert your matricies in a way that your data is still positioned relative to the camera rather than in world space.
Humas wrote an article in GPUPro 1 which describes how to handle matricies to minimize low-precision jittering.

Good luck, and I look forward to screenshots! :)


In Topic: NFAA - A Post-Process Anti-Aliasing Filter (Results, Implementation Details).

08 February 2011 - 02:46 PM

Can you describe better the process you are using? Are you using both normal and depth???

Using only the color information. At each pixel the edge direction and contrast is estimated using color differences between neighboring pixels (in our version, the color of the "central" pixel is ignored for this purpose). E.g., if it's bright on the right side and dark on the left side, then the edge has a strong vertical component (put another way, the edge normal points to the left).

In practice our sample placement represents a slightly rotated pair of basis vectors relative to the rows and columns of the image. The color differences are reduced to scalars (somehow) which become the weights for a sum of these basis vectors, and that sum is the "step size" for the directional blur.

[attachment=1191:aa filter.jpg]

Hi there 0xffffffff

I'm very interested in your approach.
Do you have any example code for your technique?


In Topic: Progressive Mesh Source Code

12 October 2010 - 01:27 PM

Here is the stuff from geometric tools.
=> http://www.geometrictools.com/LibGraphics/Detail/Detail.html
The CLOD stuff.

I used it in a product somewhere around 2004.
I can't remember the exact details of the code, but do remember that it lifted out of his engine framework rather easily.

It didn't produce the best results on some things. (eg terrains)
But it worked with minimal hassle, so was good for me at the time.

One gotcha is that if there are any verts in the vertex arrays that are unreferenced in the index buffer, it'll crash.
So be sure to do a "cleanup" pass over your mesh data first before giving it to the clod stuff.


In Topic: Progressive Mesh Source Code

26 September 2010 - 11:28 PM

David Eberlys Wild Magic toolkit has a nice implementation.