gdalgorithms-list

[Algorithms] Question to High Quality Antialiased Lines (Shader X7)/ Perspective divide

[Christian H. <c....@qu...>]

Hi out there,

I am currently working on rendering laser beams through billboards in a 
deferred rendering environment. I have strong aliasing issues when 
viewing these beams from afar as they are pretty thin with respect to 
the overall world geometry. The result is a "marching-ant" stipple-like 
pattern as shown in the attached image.

Inspired by "Simplified High-Quality-Anti-Aliased Lines" (Shader X7) I 
decided that keeping the projected beams from falling below a certain 
pixel threshold when viewed from afar (thus effectively making them 
slightly thicker) would very well solve my problems and be "plausible" 
enough.

Unfortunately, I cannot quite make sense of some of the steps in the 
shader code.

To correctly calculate the position of the corners of the billboard, the 
screen space vector between the start and endpoint is taken as such:

p0 = start * world_view_projection
p1 = end * world_view_projection

//some modifications to p0.y and p1.y according to aspect ratio
...
//Calc vectors between points in screen space <--- Original comment
delta2.xy = p1.xy / p1.z - p0.xy/p0.z;  //<----- I dont quite get why 
the divisor is z and not w (for the homogenization step after the 
projection which is my understanding of screen space)

delta_p.xy = delta2.xy
delta_p.z = p1.z - w1.z;

//Calc UV basis vectors
float len = length(delta2.xy);
float3 U = delta_p / len; //<---- Why would I not use normalize(p1/p1.w 
- p0/p0.w) as a basis for U?

...//offset = (U * factor_u + V * factor_v)


//Undo perspective divide since the hardware will do it // <---- 
Original Comment, though perspective divide to my knowledge is /w not /z
Output.position.xy += offset * Output.position.z; // <---- 
Output.position.z is p0.z or p1.z, I would multiply by Output.position.w 
here

Can somebody shed some light on this? It might be something obvious, I 
just don't see it right now.

Thanks in advance for any pointers,
other solutions for solving the stipple problem are also welcome! (i.e. 
do i need a higher tesselation to avoid rasterizing very long and thin 
triangles?)

Chris

P.S.: I made the two modifications and it still looks "correct" (i.e. I 
can't spot any differences).

Re: [Algorithms] Question to High Quality Antialiased Lines (Shader X7)/ Perspective divide

[Emil P. <hu...@co...>]

I think the z instead of w is an error in the original code. It would
probably still work fairly OK though most of the time, simply because z and
w usually are fairly close, except close to the camera (which is also why a
depth buffer often looks like plain white when viewed directly without
increasing contrast).

-Emil



-----Original Message-----
From: Christian Heckl [mailto:c....@qu...] 
Sent: 30 September 2009 23:53
To: gda...@li...
Subject: [Algorithms] Question to High Quality Antialiased Lines (Shader
X7)/ Perspective divide

Hi out there,

I am currently working on rendering laser beams through billboards in a 
deferred rendering environment. I have strong aliasing issues when 
viewing these beams from afar as they are pretty thin with respect to 
the overall world geometry. The result is a "marching-ant" stipple-like 
pattern as shown in the attached image.

Inspired by "Simplified High-Quality-Anti-Aliased Lines" (Shader X7) I 
decided that keeping the projected beams from falling below a certain 
pixel threshold when viewed from afar (thus effectively making them 
slightly thicker) would very well solve my problems and be "plausible" 
enough.

Unfortunately, I cannot quite make sense of some of the steps in the 
shader code.

To correctly calculate the position of the corners of the billboard, the 
screen space vector between the start and endpoint is taken as such:

p0 = start * world_view_projection
p1 = end * world_view_projection

//some modifications to p0.y and p1.y according to aspect ratio
...
//Calc vectors between points in screen space <--- Original comment
delta2.xy = p1.xy / p1.z - p0.xy/p0.z;  //<----- I dont quite get why 
the divisor is z and not w (for the homogenization step after the 
projection which is my understanding of screen space)

delta_p.xy = delta2.xy
delta_p.z = p1.z - w1.z;

//Calc UV basis vectors
float len = length(delta2.xy);
float3 U = delta_p / len; //<---- Why would I not use normalize(p1/p1.w 
- p0/p0.w) as a basis for U?

...//offset = (U * factor_u + V * factor_v)


//Undo perspective divide since the hardware will do it // <---- 
Original Comment, though perspective divide to my knowledge is /w not /z
Output.position.xy += offset * Output.position.z; // <---- 
Output.position.z is p0.z or p1.z, I would multiply by Output.position.w 
here

Can somebody shed some light on this? It might be something obvious, I 
just don't see it right now.

Thanks in advance for any pointers,
other solutions for solving the stipple problem are also welcome! (i.e. 
do i need a higher tesselation to avoid rasterizing very long and thin 
triangles?)

Chris

P.S.: I made the two modifications and it still looks "correct" (i.e. I 
can't spot any differences).

Re: [Algorithms] Question to High Quality Antialiased Lines (Shader X7)/ Perspective divide

[Jorge R. <jro...@ma...>]

This may be an overly simplistic or unacceptable solution, but the most
straightforward and easy solution in my mind is to make the triangles a
little bit thicker when the camera moves away, with a mandatory screen
thickness so that it always is thick enough to not show that artifact.

-- 
Jorge Rodriguez

Re: [Algorithms] Question to High Quality Antialiased Lines (Shader X7)/ Perspective divide

[Pablo de H. C. <pa...@vi...>]

On Thu, Oct 1, 2009 at 3:22 AM, Jorge Rodriguez <
jro...@ma...> wrote:

> This may be an overly simplistic or unacceptable solution, but the most
> straightforward and easy solution in my mind is to make the triangles a
> little bit thicker when the camera moves away, with a mandatory screen
> thickness so that it always is thick enough to not show that artifact.
>
> --
> Jorge Rodriguez
>
>
Me likey! Simple and practical.

Pablo
-- 
////////////////////////////////////////////////////////////////
Pablo de Heras Ciechomski, PhD, founder
pa...@vi...
phone: +41 22 534 96 25
mobile: +41 797 85 18 72
www.visualbiotech.ch