bug identified "Bad render for image's first row and column" ID 2846526

[Ricardo Mayor]

I've finally found the bug. A brief resume.
"Bad render for image's first row and column0"
I have a simple scene with a disk that covers all the screen. The disk use
a constant shader. The final render must be a white screen, but the fist
row and column is grey. It looks like the disk have a border in these row
and column.

Take a look of image "disk lengh 6.png". Is a dump of the scene centered in 0,0. The bottom right part quarter is rendered in the final image. The other quarters are no included in the final render, but they have influence during the sampling process. As you can see, only the bottom-right part of the geometry exists. The rest has been culled. In the image "disk lenght 2.png" you can see a correct geometry.

This geometry is culled during the split process in the function  CqImageBuffer::CullSurface::line 264. In this part of the code, there is a test to exclude the geometry that is not inside the camera's clipping volume.

That's the error. The clipping volume test is culling geometry needed during the sampling process.
I have to study the code, but IMHO the solution is to define the clipping volume a little bit wider to cover the geometry that have an influence in the final render. This geometry is the used during the sampling process.

This extra size is the filter's length. Obviously, this filter's length must be converted to the correct space in order to get the correct length in the volume space.

Another extra opinion. What happens with the surface modified by a displacement shader?. Maybe it's culled initially by the clipping volume test but the displacement shader introduces this surface in the influence area.

I attach the rib and the test images.

Any comments?




------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Paul Gregory-4]

Ricardo,

Well done on spending the time on this, I know the internals of Aqsis is quite hard going at times. I believe you're on absolutely the right track with this, I've done a quick test, just disabling that cull, and it seems to have the desired effect on the sample rib, as expected. The culling volume is formed in CqOptions::InitialiseCamera in options.cpp line 96, and as can clearly be seen, no account of the filter width is taken there. This is obviously what needs to be fixed. However, the right way of doing that is a subject for discussion, I'll have a think and respond to this thread later.

As for the displacement problem, that is fine, as the culling is done using the primitives bounding box, which is artificially extended to account for displacement by the "displacementbound" attribute, see the wiki docs (http://wiki.aqsis.org/doc/options#attributes) for explanation if you're not familiar.

Cheers


Paul

2009/9/6 Ricardo Mayor <ricardo.mayor@...>

I've finally found the bug. A brief resume.
"Bad render for image's first row and column0"
I have a simple scene with a disk that covers all the screen. The disk use
a constant shader. The final render must be a white screen, but the fist
row and column is grey. It looks like the disk have a border in these row
and column.

Take a look of image "disk lengh 6.png". Is a dump of the scene centered in 0,0. The bottom right part quarter is rendered in the final image. The other quarters are no included in the final render, but they have influence during the sampling process. As you can see, only the bottom-right part of the geometry exists. The rest has been culled. In the image "disk lenght 2.png" you can see a correct geometry.

This geometry is culled during the split process in the function  CqImageBuffer::CullSurface::line 264. In this part of the code, there is a test to exclude the geometry that is not inside the camera's clipping volume.

That's the error. The clipping volume test is culling geometry needed during the sampling process.
I have to study the code, but IMHO the solution is to define the clipping volume a little bit wider to cover the geometry that have an influence in the final render. This geometry is the used during the sampling process.

This extra size is the filter's length. Obviously, this filter's length must be converted to the correct space in order to get the correct length in the volume space.

Another extra opinion. What happens with the surface modified by a displacement shader?. Maybe it's culled initially by the clipping volume test but the displacement shader introduces this surface in the influence area.

I attach the rib and the test images.

Any comments?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Ricardo Mayor]

Hello,
I've been working on a patch to solve this bug. Find this patch attached in this mail. It's uploaded in the sf tracker too. The main idea is to extend the frustum planes in order to include all the geometry used during the sampling process. The code converts the screen window limits from screen coordinates to raster coordinates. The filter width are added to this limits and converted to screen coordinates. This new limits are used to calculate the frustum planes.

Best regards

On Sun, Sep 6, 2009 at 11:53 PM, Paul Gregory <pgregory@...> wrote:

Ricardo,

Well done on spending the time on this, I know the internals of Aqsis is quite hard going at times. I believe you're on absolutely the right track with this, I've done a quick test, just disabling that cull, and it seems to have the desired effect on the sample rib, as expected. The culling volume is formed in CqOptions::InitialiseCamera in options.cpp line 96, and as can clearly be seen, no account of the filter width is taken there. This is obviously what needs to be fixed. However, the right way of doing that is a subject for discussion, I'll have a think and respond to this thread later.

As for the displacement problem, that is fine, as the culling is done using the primitives bounding box, which is artificially extended to account for displacement by the "displacementbound" attribute, see the wiki docs (http://wiki.aqsis.org/doc/options#attributes) for explanation if you're not familiar.

Cheers


Paul

2009/9/6 Ricardo Mayor <ricardo.mayor@...>

I've finally found the bug. A brief resume.
"Bad render for image's first row and column0"
I have a simple scene with a disk that covers all the screen. The disk use
a constant shader. The final render must be a white screen, but the fist
row and column is grey. It looks like the disk have a border in these row
and column.

Take a look of image "disk lengh 6.png". Is a dump of the scene centered in 0,0. The bottom right part quarter is rendered in the final image. The other quarters are no included in the final render, but they have influence during the sampling process. As you can see, only the bottom-right part of the geometry exists. The rest has been culled. In the image "disk lenght 2.png" you can see a correct geometry.

This geometry is culled during the split process in the function  CqImageBuffer::CullSurface::line 264. In this part of the code, there is a test to exclude the geometry that is not inside the camera's clipping volume.

That's the error. The clipping volume test is culling geometry needed during the sampling process.
I have to study the code, but IMHO the solution is to define the clipping volume a little bit wider to cover the geometry that have an influence in the final render. This geometry is the used during the sampling process.

This extra size is the filter's length. Obviously, this filter's length must be converted to the correct space in order to get the correct length in the volume space.

Another extra opinion. What happens with the surface modified by a displacement shader?. Maybe it's culled initially by the clipping volume test but the displacement shader introduces this surface in the influence area.

I attach the rib and the test images.

Any comments?

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[filascol.patch]

---

diff --git a/libs/core/options.cpp b/libs/core/options.cpp
index f18469f..85e0287 100644
--- a/libs/core/options.cpp
+++ b/libs/core/options.cpp
@@ -85,28 +85,51 @@ void CqOptions::InitialiseCamera()
  CqMatrix T;
  T.Translate( 1, 1, 0 );
  // Scale by 0.5 (0,0 --> 1,1) NDC
- CqMatrix S( 0.5, 0.5, 0 );
- CqMatrix S2( FrameX, FrameY, 0 );
+ CqMatrix S( 0.5, 0.5, 1.0f );
+ CqMatrix S2( FrameX, FrameY,  1.0f );
  // Invert y to fit top down format
  CqMatrix S3( 1, -1, 1 );
  matScreenToNDC = S * T * S3; // S*T*S2
  matNDCToRaster = S2;
-
- // Setup the view frustum clipping volume
+
+ //Calculate a frame extension for the screen window.  
+ //This frame extension is equal to the current filter width
+ CqMatrix matRasterToScreen = (matNDCToRaster * matScreenToNDC ).Inverse();
+ TqFloat filterWidthX = std::ceil(GetFloatOption( "System", "FilterWidth" ) [ 0 ] ) * 0.5f ;
+ TqFloat filterWidthY = std::ceil(GetFloatOption( "System", "FilterWidth" ) [ 1 ] ) * 0.5f;
+ CqVector3D frameExtension( filterWidthX,  filterWidthY, 0);
+
+ //Calculate extra frame in the Raster space
+ CqVector3D rightBottom , leftTop, leftTopScreen,rightBottomScreen;
+ leftTop = ((matNDCToRaster * matScreenToNDC ) * CqVector3D(l, t, 0)) - frameExtension;
+ rightBottom = ((matNDCToRaster * matScreenToNDC ) * CqVector3D(r, b, 0)) + frameExtension;
+
+ //Get new view frustrum planes in the Screen space
+ leftTopScreen = matRasterToScreen * leftTop;
+ rightBottomScreen = matRasterToScreen * rightBottom;
+
+ TqFloat newL , newB , newR , newT ;
+
+ newL = leftTopScreen.x();
+ newT = leftTopScreen.y();
+ newB = rightBottomScreen.y();
+ newR = rightBottomScreen.x();
+
+ // Setup the view frustum clDipping volume
  // Left clipping plane
- CqPlane pl(1,0,0,fabs(l));
+ CqPlane pl(1,0,0,fabs(newL));
  QGetRenderContext()->clippingVolume().addPlane(pl);
 
  // Right clipping plane
- CqPlane pr(-1,0,0,fabs(r));
+ CqPlane pr(-1,0,0,fabs(newR));
  QGetRenderContext()->clippingVolume().addPlane(pr);
 
  // Top clipping plane
- CqPlane pt(0,-1,0,fabs(t));
+ CqPlane pt(0,-1,0,fabs(newT));
  QGetRenderContext()->clippingVolume().addPlane(pt);
 
  // Bottom clipping plane
- CqPlane pb(0,1,0,fabs(b));
+ CqPlane pb(0,1,0,fabs(newB));
  QGetRenderContext()->clippingVolume().addPlane(pb);
 
  // Near clipping plane
@@ -163,33 +186,57 @@ void CqOptions::InitialiseCamera()
  matScreenToNDC = S * T * S3; // S*T*S2
  matNDCToRaster = S2;
 
+ //Calculate a frame extension for the screen window.  
+ //This frame extension is equal to the current filter width
+ CqMatrix matRasterToScreen = (matNDCToRaster * matScreenToNDC ).Inverse();
+ TqFloat filterWidthX = std::ceil(GetFloatOption( "System", "FilterWidth" ) [ 0 ] ) * 0.5f ;
+ TqFloat filterWidthY = std::ceil(GetFloatOption( "System", "FilterWidth" ) [ 1 ] ) * 0.5f;
+ CqVector3D frameExtension( filterWidthX,  filterWidthY, 0);
+
+ //Calculate extra frame in the Raster space
+ CqVector3D rightBottom , leftTop, leftTopScreen,rightBottomScreen;
+ leftTop = ((matNDCToRaster * matScreenToNDC ) * CqVector3D(l, t, 0)) - frameExtension;
+ rightBottom = ((matNDCToRaster * matScreenToNDC ) * CqVector3D(r, b, 0)) + frameExtension;
+
+ //Get new view frustrum planes in the Screen space
+ leftTopScreen = matRasterToScreen * leftTop;
+ rightBottomScreen = matRasterToScreen * rightBottom;
+
+ TqFloat newL , newB , newR , newT ;
+
+ newL = leftTopScreen.x();
+ newT = leftTopScreen.y();
+ newB = rightBottomScreen.y();
+ newR = rightBottomScreen.x();
+
+
  // Setup the view frustum clipping volume
  // Left clipping plane
- CqPlane pl(matCameraToScreen[0][3] + matCameraToScreen[0][0],
-           matCameraToScreen[1][3] + matCameraToScreen[1][0],
-           matCameraToScreen[2][3] + matCameraToScreen[2][0],
-           matCameraToScreen[3][3] + matCameraToScreen[3][0]);
+ CqPlane pl(matCameraToScreen[0][3] + matCameraToScreen[0][0] * newL,
+           matCameraToScreen[1][3] + matCameraToScreen[1][0] * newL,
+           matCameraToScreen[2][3] + matCameraToScreen[2][0] * newL,
+           matCameraToScreen[3][3] + matCameraToScreen[3][0] * newL);
  QGetRenderContext()->clippingVolume().addPlane(pl);
 
  // Right clipping plane
- CqPlane pr(matCameraToScreen[0][3] - matCameraToScreen[0][0],
-           matCameraToScreen[1][3] - matCameraToScreen[1][0],
-           matCameraToScreen[2][3] - matCameraToScreen[2][0],
-           matCameraToScreen[3][3] - matCameraToScreen[3][0]);
+ CqPlane pr(matCameraToScreen[0][3] - matCameraToScreen[0][0] * newR,
+           matCameraToScreen[1][3] - matCameraToScreen[1][0] * newR,
+           matCameraToScreen[2][3] - matCameraToScreen[2][0] * newR,
+           matCameraToScreen[3][3] - matCameraToScreen[3][0] * newR);
  QGetRenderContext()->clippingVolume().addPlane(pr);
 
  // Top clipping plane
- CqPlane pt(matCameraToScreen[0][3] - matCameraToScreen[0][1],
-           matCameraToScreen[1][3] - matCameraToScreen[1][1],
-           matCameraToScreen[2][3] - matCameraToScreen[2][1],
-           matCameraToScreen[3][3] - matCameraToScreen[3][1]);
+ CqPlane pt(matCameraToScreen[0][3] - matCameraToScreen[0][1] * newT,
+           matCameraToScreen[1][3] - matCameraToScreen[1][1] * newT,
+           matCameraToScreen[2][3] - matCameraToScreen[2][1] * newT,
+           matCameraToScreen[3][3] - matCameraToScreen[3][1] * newT);
  QGetRenderContext()->clippingVolume().addPlane(pt);
 
  // Bottom clipping plane
- CqPlane pb(matCameraToScreen[0][3] + matCameraToScreen[0][1],
-           matCameraToScreen[1][3] + matCameraToScreen[1][1],
-           matCameraToScreen[2][3] + matCameraToScreen[2][1],
-           matCameraToScreen[3][3] + matCameraToScreen[3][1]);
+ CqPlane pb(matCameraToScreen[0][3] + matCameraToScreen[0][1] * newB,
+           matCameraToScreen[1][3] + matCameraToScreen[1][1] * newB,
+           matCameraToScreen[2][3] + matCameraToScreen[2][1] * newB,
+           matCameraToScreen[3][3] + matCameraToScreen[3][1] * newB);
  QGetRenderContext()->clippingVolume().addPlane(pb);
 
  // Near clipping plane

---

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Aqsis-development mailing list
Aqsis-development@...
https://lists.sourceforge.net/lists/listinfo/aqsis-development

[Chris Foster-5]

On Sat, Sep 12, 2009 at 11:48 PM, Ricardo Mayor <ricardo.mayor@...> wrote:
> Hello,
> I've been working on a patch to solve this bug. Find this patch attached in
> this mail. It's uploaded in the sf tracker too. The main idea is to extend
> the frustum planes in order to include all the geometry used during the
> sampling process. The code converts the screen window limits from screen
> coordinates to raster coordinates. The filter width are added to this limits
> and converted to screen coordinates. This new limits are used to calculate
> the frustum planes.

This sounds like a reasonable approach.  Before I look at the patch in
detail, it's probably worth getting some word from Paul on the related
DoF issue.  I'd like to understand the reasons for doing frustrum
culling in the first place, rather than simply culling based on raster
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

[T G-3]

Really not sure if this is the right place to do this but - there is
some serious bug I think sort of related to this, though mind you I
have no idea, either way it is a bad one. This render was done late
last night using the 9/13 build of Aqsis.

http://picasaweb.google.com/lh/photo/o_14iqq9EKjUPbXNQO8_vw?authkey=Gv1sRgCKqP9vT19rGp0QE&feat=directlink

As you can see in this render the wall seems to be culled for half the
render on the left side, but not the right. This seems to be similar
to the earlier bugs I had seen last week, only that now they are
worse. It would make sense if it was displacement related, or bounding
box related but the objects that are being culled are quite a distance
away from the camera. I honestly do not have a clue as to what the
issue really is but it's a bad one.

Ted

------------------------------------------------------------------------------
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 Ted,

On Wed, Sep 16, 2009 at 3:34 AM, T G <animate1978@...> wrote:
> Really not sure if this is the right place to do this

The best place to report bugs is our bugtracker:

http://sourceforge.net/tracker/?group_id=25264&atid=383970

though the mailing list or aqsis forum is also acceptable.  The most important
thing is that you provide a test case so we can reproduce the bug ourselves.

> but - there is
> some serious bug I think sort of related to this, though mind you I
> have no idea, either way it is a bad one. This render was done late
> last night using the 9/13 build of Aqsis.
>
> http://picasaweb.google.com/lh/photo/o_14iqq9EKjUPbXNQO8_vw?authkey=Gv1sRgCKqP9vT19rGp0QE&feat=directlink
>
> As you can see in this render the wall seems to be culled for half the
> render on the left side, but not the right.

Yes, this looks wrong of course.  I'll reiterate what I said the other day on
the project widow forums: please send us a test case (RIB+sl format) and we'll
look into it.  If you can do it soon, we may be able to fix it before 1.6 is
released ;-)

The better the bug report is, the more chance we will have of fixing it
quickly.  A good bug report contains:

* Clear instructions to reproduce (*most* important).  Usually this would be a
  test case in our native format (RIB / RSL source).  Sources for the test
  case are also welcome (eg, a .blend file) but should be in *addition* to the
  native format if at all possible.  (RIB format is good because it doesn't
  require on any external tools so lets us reproduce the bug with minimum fuss.)

* Obvious or carefully described symptoms.

* We like test cases which are simple:
  - Small amounts of geometry (preferably only one primitive, with a simple
    mesh if it's a mesh-like primitive type)
  - Simple shaders if possible, though complex shaders can be easier to reduce
    than complex geometry in RIB format.

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