constant vs smooth shading interpolation

[Matthias Baas-3]

Hi,

this is basically a followup to my bug report 2862585
(http://sourceforge.net/tracker/?func=detail&aid=2862585&group_id=25264&atid=383970).
I thought I rather post here instead of adding a reply to the bug report
(which is closed anyway). I think Chris' solution to switch to smooth
shading interpolation is fair enough, I'm just posting to make sure I
understand the problem correctly.

Basically, there's one question left for me: in constant interpolation
mode, at what point is the shading actually done? Is it just one of the
micro polygon vertex? If so, which one? Is that the problem in my
example scene that where the two triangles meet, the micro polygons are
oriented in the "opposite" way which means the shading locations are two
micro polygons apart instead of just one which leads to this discontinuity?

I also rendered that scene using PRMan and 3Delight. Both of them
produce micro polygons whose sides are parallel to the initial polygon
(which means there is no artifact in this example). Does that mean they
don't split up the quad into two triangles but rather handle quads
separately?

When I further played around with that scene I found another thing that
looks odd to me. When you replace the polygon by this one (which just
has an additional vertex):

PointsGeneralPolygons [1] [5] [0 1 3 2 4] "P" [-1 0 1  1 0 1  -1 0 -1  1
0 -1  -0.5 0 0]

and increase the shading rate to 80 (so that you can easily see what's
going on), then the results of Aqsis and 3Delight in the lower part of
the image actually look similar (the micro polygons are oriented
differently but after all, that's up to the renderer). The odd thing is
the triangle on the far side. In 3Delight's case, you can easily spot
the micro polygons just like in the lower part. They even seem to be a
bit larger which I guess is just because they are further away (and
maybe just appear larger? I didn't count pixels) but in Aqsis's case,
that triangle almost looks as if it was smooth shaded. It seems Aqsis
produces far more micro polygons than necessary (according to the stats
it's 1233 vs 902). How does it determine the number of micro polygons to
create?

- Matthias -

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

Hi Matthias,

On Wed, Sep 23, 2009 at 7:44 AM, Matthias Baas <matthias.baas@...> wrote:

> Hi,
>
> this is basically a followup to my bug report 2862585
> (http://sourceforge.net/tracker/?func=detail&aid=2862585&group_id=25264&atid=383970).
> I thought I rather post here instead of adding a reply to the bug report
> (which is closed anyway). I think Chris' solution to switch to smooth
> shading interpolation is fair enough, I'm just posting to make sure I
> understand the problem correctly.
>
> Basically, there's one question left for me: in constant interpolation
> mode, at what point is the shading actually done? Is it just one of the
> micro polygon vertex? If so, which one? Is that the problem in my
> example scene that where the two triangles meet, the micro polygons are
> oriented in the "opposite" way which means the shading locations are two
> micro polygons apart instead of just one which leads to this discontinuity?

Yes, that is basically the problem.  It's important to realise that the value
of ShadingInterpolation in no way influences how the shading itself is done,
which is _always_ at the vertices of a micropolygon grid.  Instead, the
shading interpolation effects how the results of running the shader program
are interpolated across the faces of individual micropolygons:

ShadingInterpolation "constant":
  Constant interpolation means that each micropolygon is flat shaded, with the
  colour coming from a single vertex.  The micropolygon at position (iu,iv) on
  a grid is shaded with the colour from vertex (iu,iv) so that there's
  effectively half a micropolygon width offset between the centre of the
  micropolygon and the position at which the shading result was computed.

ShadingInterpolation "smooth":
  Smooth (or gouraud) shading causes the colour of the four vertices to be
  interpolated bilinearly across the face of the micropolygon.  In this case
  there's no offset bias between the position of the shading point and the
  effects it has in the output image.

Since a grid has no information about its neighbours, it can happen that the
grid indices iu and iv could increase in different directions.  As you
noticed, this is a problem for constant interpolation because it causes a
micropolygon's width of "shear" in the output image.

> I also rendered that scene using PRMan and 3Delight. Both of them
> produce micro polygons whose sides are parallel to the initial polygon
> (which means there is no artifact in this example). Does that mean they
> don't split up the quad into two triangles but rather handle quads
> separately?

Most likely I would say.  This would just require detecting when a general
polygon was actually a convex quad, which is pretty easy I think.

> When I further played around with that scene I found another thing that
> looks odd to me. When you replace the polygon by this one (which just
> has an additional vertex):
>
> PointsGeneralPolygons [1] [5] [0 1 3 2 4] "P" [-1 0 1  1 0 1  -1 0 -1  1
> 0 -1  -0.5 0 0]
>
> and increase the shading rate to 80 (so that you can easily see what's
> going on), then the results of Aqsis and 3Delight in the lower part of
> the image actually look similar (the micro polygons are oriented
> differently but after all, that's up to the renderer). The odd thing is
> the triangle on the far side. In 3Delight's case, you can easily spot
> the micro polygons just like in the lower part. They even seem to be a
> bit larger which I guess is just because they are further away (and
> maybe just appear larger? I didn't count pixels) but in Aqsis's case,
> that triangle almost looks as if it was smooth shaded. It seems Aqsis
> produces far more micro polygons than necessary (according to the stats
> it's 1233 vs 902). How does it determine the number of micro polygons to
> create?

Aqsis computes the length of the primitive in the u-direction, and the length
in the v-direction in raster space.  It then divides these by
sqrt(ShadingRate) to estimate the number of micropolygons needed in each
direction.  This is appropriate and accurate when the sides of a grid are
nearly perpendicular.

It's probable that this goes wrong in your test scene because the triangle at
the back is quite long and skinny.  The area of the micropolygons arising from
such a triangle is much smaller than what the simple estimate based on
perpendicular u and v directions would suggest.  Therefore aqsis overestimates
the dicing rate.

I think this would be fairly easy to fix (at least for bilinear patches) using
the magnitude of the cross product of the two sides.  This has an appropriate
scaling factor of sin(angle_between_the_sides) so that it computes a much
better estimate of the expected area of the bilinear patch.

Cheers,
~Chris.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Wed, Sep 23, 2009 at 9:29 AM, Chris Foster <chris42f@...> wrote:
> I think this would be fairly easy to fix (at least for bilinear patches) using
> the magnitude of the cross product of the two sides.  This has an appropriate
> scaling factor of sin(angle_between_the_sides) so that it computes a much
> better estimate of the expected area of the bilinear patch.

Hmm, or maybe this isn't really the right thing to do.  It would result in a
more accurate micropolygon *area*, but the tradeoff would be micropolygons
which are relatively large in linear dimension with possible artifacts...


One thing which I'd guess is definitely worth doing is to improve the way that
triangles are turned into patches.  Currently, a triangle is turned into a
patch with a random orientation, but this can result in unnecessarily long
skinny patches.

Consider the triangle

  x
  |\
  | \
  |  \
  x---x

one way to turn this into a patch with a phantom fourth vertex (indicated by
'o') is

  x
  |\
  | \
  |  \
  x---x
   \  |
    \ |
     \|
      o

but this results in long skinny micropolygons (micropolys have the same shape
as the parent patch).  Alternatively, the original triangle could be turned
into the following:

  x---o
  |\  |
  | \ |
  |  \|
  x---x

which has square micropolygons which are much better.


Looking at the current code, I see that this has actually been implemented in
the past, but was commented out in 2006, apparently for the reason:

/* Comment this out for now as it breaks Bug948827 in a strange way,
needs more investigation */

presumably this wouldn't be too hard to fix.

~Chris.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Matthias Baas-3]

Hi Chris,

> Yes, that is basically the problem.  It's important to realise that the value
> of ShadingInterpolation in no way influences how the shading itself is done,
> which is _always_ at the vertices of a micropolygon grid.  Instead, the
> shading interpolation effects how the results of running the shader program
> are interpolated across the faces of individual micropolygons:
>
> ShadingInterpolation "constant":
>   Constant interpolation means that each micropolygon is flat shaded, with the
>   colour coming from a single vertex.  The micropolygon at position (iu,iv) on
>   a grid is shaded with the colour from vertex (iu,iv) so that there's
>   effectively half a micropolygon width offset between the centre of the
>   micropolygon and the position at which the shading result was computed.

ok, so this means there is always a row and column of vertices that are
unused and I guess from the renderer's point of view it would be just as
correct if micropoly (iu,iv) would get the color from vertex (iu+1,iv),
(iu,iv+1) or (iu+1, iv+1) (i.e. from any of the other micropoly vertices).
Couldn't this be exploited to make the shading across grids more
uniform? Maybe the orientation of the grid in space could be used to
decide whether the "lower" or the "upper" row/column of vertices is
ignored. For example, if the vertex coordinates in one direction (say x
direction) are increasing, then use iu, otherwise use iu+1 and the same
in v direction. What I mean is, the micropolys from a grid that is
rotated around by 180 degrees should then get the same shading values
than the micropolys from the unrotated grid and that artifact in the bug
report would hopefully go away, even in constant shading interpolation mode.
Or alternatively, would it be an option to shader the micropolys at
their centers?

>> that triangle almost looks as if it was smooth shaded. It seems Aqsis
>> produces far more micro polygons than necessary (according to the stats
>> it's 1233 vs 902). How does it determine the number of micro polygons to
>> create?
>
> Aqsis computes the length of the primitive in the u-direction, and the length
> in the v-direction in raster space.  It then divides these by
> sqrt(ShadingRate) to estimate the number of micropolygons needed in each
> direction.  This is appropriate and accurate when the sides of a grid are
> nearly perpendicular.
>
> It's probable that this goes wrong in your test scene because the triangle at
> the back is quite long and skinny.  

This is already considered to be long and skinny? Then I suppose most
triangles are. ;)
Maybe I can eventually do some more test scenes to investigate this further.

Cheers,

- Matthias -

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Fri, Sep 25, 2009 at 7:02 AM, Matthias Baas <matthias.baas@...> wrote:

> Hi Chris,
>
>> Yes, that is basically the problem.  It's important to realise that the value
>> of ShadingInterpolation in no way influences how the shading itself is done,
>> which is _always_ at the vertices of a micropolygon grid.  Instead, the
>> shading interpolation effects how the results of running the shader program
>> are interpolated across the faces of individual micropolygons:
>>
>> ShadingInterpolation "constant":
>>   Constant interpolation means that each micropolygon is flat shaded, with the
>>   colour coming from a single vertex.  The micropolygon at position (iu,iv) on
>>   a grid is shaded with the colour from vertex (iu,iv) so that there's
>>   effectively half a micropolygon width offset between the centre of the
>>   micropolygon and the position at which the shading result was computed.
>
> ok, so this means there is always a row and column of vertices that are
> unused and I guess from the renderer's point of view it would be just as
> correct if micropoly (iu,iv) would get the color from vertex (iu+1,iv),
> (iu,iv+1) or (iu+1, iv+1) (i.e. from any of the other micropoly vertices).
> Couldn't this be exploited to make the shading across grids more
> uniform?

Yes, I could imagine doing this to some extent but it will never work
in full generality.  (To see why, consider trying to shade a
nonorientable manifold like the Mobius strip!)  In practise it would
be sufficient that the places where the directions of increasing u and
v are inconsistent are where the surface is tangent to the view
direction.

> Maybe the orientation of the grid in space could be used to
> decide whether the "lower" or the "upper" row/column of vertices is
> ignored. For example, if the vertex coordinates in one direction (say x
> direction) are increasing, then use iu, otherwise use iu+1 and the same
> in v direction. What I mean is, the micropolys from a grid that is
> rotated around by 180 degrees should then get the same shading values
> than the micropolys from the unrotated grid and that artifact in the bug
> report would hopefully go away, even in constant shading interpolation mode.
> Or alternatively, would it be an option to shader the micropolys at
> their centers?

It's possible in principle, but probably not desirable in practise: it
requires that surface shading run on a different grid from the
displacement shader, which at the least implies a cost in code
complexity.

I'm sure we could come up with a number of complex workarounds, but
TBH I don't know why we'd bother because we already have one: it's
called smooth shading interpolation!

~Chris.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Matthias Baas-3]

Hi Chris,

Chris Foster wrote:
> I'm sure we could come up with a number of complex workarounds, but
> TBH I don't know why we'd bother because we already have one: it's
> called smooth shading interpolation!

True, in particular when it's the default now. I suppose improving
constant interpolation only makes sense when there is a noticeable
performance benefit. I just did a quick test with that scene from the
bug report and rendered it using a very low shading rate (to create more
micro polys). Smooth shading was only slightly slower and I suppose that
difference will get even smaller once there is more complex geometry and
shading involved. So, just using smooth interpolation is fine by me. :)

Cheers,

- Matthias -

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Mon, Sep 28, 2009 at 7:23 AM, Matthias Baas <matthias.baas@...> wrote:
> True, in particular when it's the default now. I suppose improving
> constant interpolation only makes sense when there is a noticeable
> performance benefit. I just did a quick test with that scene from the
> bug report and rendered it using a very low shading rate (to create more
> micro polys). Smooth shading was only slightly slower and I suppose that
> difference will get even smaller once there is more complex geometry and
> shading involved. So, just using smooth interpolation is fine by me. :)

Note that the smooth shading implementation has changed completely
since 1.4, but I think the conclusion that the speed hit is fairly
minor (when compared to other costs of complex scenes) tends to be
generally true.  Overall I think that defaulting to smooth is a win
compared to dealing with the confusing artefacts which come up every
now and then with constant interpolation.

Note also that the hit depth always needs better than constant
interpolation for proper hiding (in aqsis-1.4 it was a kind of halfway
smooth interpolation).  In the new implementation smooth interpolation
is used for the depth so some of the cost of smooth interpolation is
always present due to the need to calculate z accurately (that is, the
cost of reverse bilinear lookup from the hit location to micropolygon
u,v coordinates).

~Chris.

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development