[vtkusers] Re2: My investigation results on the three vtkOpenGLGPUVolumeRayCastMapper bugs. Please read!

AGPX agpxnet at yahoo.it
Thu Aug 12 08:56:32 EDT 2010


However, the numbers are 8548 and 8549. 8548 could be closed indeed...




________________________________
Da: Dave Partyka <dave.partyka at kitware.com>
A: AGPX <agpxnet at yahoo.it>
Cc: vtk vtk <vtkusers at vtk.org>
Inviato: Gio 12 agosto 2010, 14:51:47
Oggetto: Re: [vtkusers] My investigation results on the three 
vtkOpenGLGPUVolumeRayCastMapper bugs. Please read!

Wow! Thank you for the bug fixes! Can you send the changes as a git patch. See 
here for how to create one.

http://vtk.org/Wiki/VTK/Git#Submitting_a_patch

Also can you provide the bug tracker numbers so we can mark them as closed. 
Thanks!

On Thu, Aug 12, 2010 at 5:29 AM, AGPX <agpxnet at yahoo.it> wrote:

Hi to all,
>
>I have the time to address the 3 ancients bugs that affect the mapper 
>vtkOpenGLGPUVolumeRayCastMapper, discovered and signaled on mantis bugtracer by 
>me on February 2009 (bugs never solved). These bugs make the mapper quite 
>unusable and this is a serious issue because that mapper is the best compromise 
>between quality and speed for volume rendering.
>OK, we have 3 different issue. Let me talk about the three.
>
>1) Plane clipping bugs (to better figure out the problem, here a video of the 
>problem: http://www.youtube.com/watch?v=NjUTTA86yTM&feature=related). I have 
>solved this bug. The problem is in the method: 
>vtkOpenGLGPUVolumeRayCastMapper::RenderClippedBoundingBox. That method check the 
>correct winding  order of the polygon and fails its job. Actually the algorithm 
>check the relationship between the polygon plane and the SPATIAL center of the 
>volume. Note that the volume is always convex. The problem is that you haven't 
>to use spatial center, but center of mass. If you use spatial center (center of 
>bounding box) you wrong because it not always lie inside the convex polyhedra: 
>it could lie on a polygon boundary plane. Let me show this in 2D:
>
> __________
>|         /
>|        /
>|       /
>|      /
>|     x
>|    /
>|   /
>|  /
>| /
>|/
>
>If you have a triangle, the spatial center lie on an edge and due to floating 
>point inaccuracy this point could lie  in front or behind the plane. When point 
>lie behind the plane the algorithm flip the vertex order resulting in back-faced 
>polygon. The solution is to compute center of mass (average of vertices):
>
> __________
>|         /
>|        /
>|       /
>|      /
>|  x  /
>|    /
>|   /
>|  /
>| /
>|/
>
>The center of mass always lie inside the convex polyhedra and this solve the 
>problem.
>
>Here my fix (in vtkOpenGLGPUVolumeRayCastMapper::RenderClippedBoundingBox):
>
>  double center[3] = {0,0,0};
>  double min[3] = {VTK_DOUBLE_MAX, VTK_DOUBLE_MAX, VTK_DOUBLE_MAX};
>  double max[3] = {VTK_DOUBLE_MIN, VTK_DOUBLE_MIN, VTK_DOUBLE_MIN};
>
>  // First compute center point
>  npts = points->GetNumberOfPoints();
>  for ( i = 0; i < npts; i++ )
>    {
>    double pt[3];
>    points->GetPoint( i, pt );
>    for ( j = 0; j < 3; j++ )
>      {
>          // AGPX MODIFIED
>//       min[j] = (pt[j]<min[j])?(pt[j]):(min[j]);
>//      max[j] = (pt[j]>max[j])?(pt[j]):(max[j]);
>          center[j] += pt[j];
>          // AGPX MODIFIED
>      }
>    }
>
> // AGPX MODIFIED
>  //center[0] = 0.5*(min[0]+max[0]);
>  //center[1] = 0.5*(min[1]+max[1]);
>  //center[2] = 0.5*(min[2]+max[2]);
>  center[0] /= ((double)npts);
>  center[1] /= ((double)npts);
>  center[2] /=  ((double)npts);
> // AGPX MODIFIED
>
>This completely solve this issue. Now go to the next bug.
>
>2) "Volume disappearing". Suddenly, if you fly-through inside a volume, it can 
>disappear. The problem is related to the near clipping plane. Actually the 
>method vtkOpenGLGPUVolumeRayCastMapper::ClipBoundingBox, clip the volume box 
>with the near clipping plane (and eventually also with custom clip planes) in 
>order to avoid that the volume results opened. The problem is that due to 
>floating point inaccuracy the resulting clipped convex polyhedra could be still 
>opened! The problem could be solved pushing the near clipping plane slightly 
>ahead. That is:
>
>if(this->NearPlane==0)
>    {
>    this->NearPlane= vtkPlane::New();
>    }
>
>  // AGPX ADDED
>  const double offset = 0.01;
>  camNearPoint[0] += camPlaneNormal[0] * offset;
>  camNearPoint[1] += camPlaneNormal[1] * offset;
>  camNearPoint[2] += camPlaneNormal[2] * offset;
>  // AGPX ADDED
>
>  this->NearPlane->SetOrigin( camNearPoint );
>  this->NearPlane->SetNormal( camPlaneNormal );
>   this->Planes->AddItem(this->NearPlane);
>
>The problem here is to establish how much you have to push plane ahead. 0.01 is 
>working for me. Ok, following me to the last (hard) bug.
>
>3) Volume Rendering Deformation. This bug show a non correct rendering of the 
>volume when you perform a fly-through inside a volume (here 
>http://www.youtube.com/watch?gl=IT&hl=it&v=C_GA6UHbUGo you can see a video of 
>the problem). Actually this bug is unsolved and here I need some help from 
>authors. Look like a bad entry-ray and/or ray-direction calculation. The problem 
>is showed only when the near clipping plane clips the volume box. The entry 
>point is given by the texture coordinate of the point being rasterized (a 3D 
>texture coordinate is applied to the vertices of the rendered volume box). This 
>look like correct. The ray direction is given by the difference  between the 
>entry point and the camera position in texture space. This should be always ok. 
>The method vtkOpenGLGPUVolumeRayCastMapper::LoadProjectionParameters computed 
>the camera position in texture space and looks correct (notice that I'm always 
>talking about a perspective camera):
>
>double *bounds=this->CurrentScalar->GetLoadedBounds();
>
>  double dx=bounds[1]-bounds[0];
>  double  dy=bounds[3]-bounds[2];
>  double dz=bounds[5]-bounds[4];
>
>
> // Perspective projection
>
>    // Compute camera position in texture coordinates
>    // Position of the center of the camera in world frame
>    double cameraPosWorld[4];
>    // Position of the center of the camera in the dataset frame
>    // (the transform of the volume is taken into account)
>    double cameraPosDataset[4];
>   // Position of the center of the camera in the texture frame
>    // the coordinates are translated and rescaled
>    double cameraPosTexture[4];
>
>    ren->GetActiveCamera()->GetPosition(cameraPosWorld);
>    cameraPosWorld[3]=1.0; // we use homogeneous coordinates.
>
>     datasetToWorld->MultiplyPoint(cameraPosWorld,cameraPosDataset);
>
>   // From homogeneous to cartesian coordinates.
>    if(cameraPosDataset[3]!=1.0)
>      {
>      double ratio=1/cameraPosDataset[3];
>      cameraPosDataset[0]*=ratio;
>      cameraPosDataset[1]*=ratio;
>      cameraPosDataset[2]*=ratio;
>      }
>
>    cameraPosTexture[0] = (cameraPosDataset[0]-bounds[0])/dx;
>    cameraPosTexture[1] = (cameraPosDataset[1]-bounds[2])/dy;
>    cameraPosTexture[2] = (cameraPosDataset[2]-bounds[4])/dz;
>
>Ray  direction is computed by the shader 
>(vtkGPUVolumeRayCastMapper_PerspectiveProjectionFS.glsl):
>
>// Entry position (global scope)
>vec3 pos;
>// Incremental vector in texture space (global scope)
>vec3 rayDir;
>// Camera position in texture space
>uniform vec3 cameraPosition;
>
>// Defined in the right projection method.
>void incrementalRayDirection()
>{
>  // Direction of the ray  in texture space, not normalized.
>  rayDir=pos-cameraPosition;
>  ...
>}
>
>and looks correct.
>
>The entry point seems correct, because if I use a totally opaque volume (in 
>order to avoid ray traversal, that is the algorithm stop immediately on the 
>first hitted voxel) and clipped with a plane to enter inside it, the rendering 
>is always ok. That is entry point looks correct. When the volume isn't fully 
>opaque the result is wrong. So, I suspect that the ray direction is wrong. Note 
>that the problem disappear (or at least is not much  noticeable) IF I try push 
>the near clipping plane ahead of a greater quantity (>> 0.01). If I push it 
>ahead of 16.0 instead of 0.01 (as stated in the previous bug), the deformation 
>is not very noticeable. Note that 16.0 is an empirically determinated value for 
>my tested datasets and reasonably it's not a valid choice for every dataset (a 
>way to determine a good value?). It's not clear why the near clipping plane 
>cause this problem. The texture coordinate seems to be interpolated correctly 
>and apparently there are no reason why the method should not works. Here I'm 
>stuck and I need some help from some CG Guru! Please support!
>
>Thanks in advance for your attention.
>
>_______________________________________________
>Powered by www.kitware.com
>
>Visit other Kitware open-source projects at 
>http://www.kitware.com/opensource/opensource.html
>
>Please keep messages on-topic and check the VTK FAQ at: 
>http://www.vtk.org/Wiki/VTK_FAQ
>
>Follow this link to subscribe/unsubscribe:
>http://www.vtk.org/mailman/listinfo/vtkusers
>
>



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20100812/5495423b/attachment.htm>


More information about the vtkusers mailing list