[vtkusers] Bug in depth ordering whilst rendering

Peter Clifton pcjc2 at cam.ac.uk
Wed Nov 28 04:10:22 EST 2007


On Wed, 2007-11-28 at 00:49 -0800, David Thompson wrote:
> > Do any developers hang out here?
> Yes.
> 
> > I appreciate that having no reply to a question (in what is arguably a
> > short time so far), can indicate many things..
> >
> > * Question asked in wrong place
> > * Question missing information
> > * Question containing too much information
> >
> > If anyone is familiar with the rendering code, perhaps they will be  
> > able
> > to point me in the right direction.
> Depth peeling does not appear to be in VTK 5.0.x. It is present in the  
> CVS trunk. See http://www.vtk.org/Wiki/VTK/Depth_Peeling for some  
> information on how to use it (note the list of GL extensions you need  
> in order for it to work). Shy of depth peeling,
> 
> > I doubt this is a VTK bug in the strictest sense (as MESA software
> > rendering seemed to "fix" it), but without knowing what underlying  
> > cause
> > is, or having a simple gl / glut test case, reporting a MESA bug isn't
> > yet going to get much attention either.
> It is not a bug. Without depth peeling, geometry primitives must be  
> depth-sorted each time the camera changes. This is not a trivial  
> amount of work for large datasets and many people don't have  
> transparent geometry to render, so depth sorting is something you must  
> set up in your pipeline if you want it to be done (see  
> vtkDepthSortPolyData). Without depth sorting, you will see some  
> triangles blended into the color buffer in the wrong order. Without a  
> screen capture or more details, I would guess that is what you are  
> reporting.

It does sound like it, however I "think" I'm seeing this with
non-translucent objects too (although not in the TextureThreshold.py
example). I can post some screen-shots, and simple Python + VTK example
code when I'm at the lab later.

I'll do some tests based on your suggestions, and get back to you. What
is strange, is MESA software rendering clears up the bug for me in the
case I tested (not TextureThreshold.py).

This also manifests with viewer, if I toggle on the coordinate mark
(x,y,z lines with cones pointing in their directions). The coordinate
arrows end up drawn in the wrong Z order. (Would I need to sort the poly
data for these to draw correctly too?)

I'm also trying to build the CVS head of VTK, as if depth peeling solves
the issue, I'll be sorted.

As its a complex piece of software, I'm trying to build it as a debian
package so I can just dpkg --install it to replace the current version
I've got installed without fear of breaking my system. The package
building process makes any build failures much more time-consuming to
fix though!

Many thanks,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)




More information about the vtkusers mailing list