.TH "SoPolygonOffset" 3 "Thu May 29 2014" "Version 4.0.0a" "Coin" \" -*- nroff -*-
.ad l
.nh
.SH NAME
SoPolygonOffset \- 
.PP
The \fBSoPolygonOffset\fP class is a node type for 'layering' rendering primitives\&.
.PP
A common problem with realtime 3D rendering systems is that rendered primitives which are at approximately the same depth with regard to the camera viewpoint will appear to flicker\&. I\&.e\&.: from one angle one primitive will appear to be closer, while at another angle, another primitive will appear closer\&. When this happens, the rendered graphics at that part of the scene will of course look a lot less visually pleasing\&.  

.SH SYNOPSIS
.br
.PP
.PP
\fC#include <Inventor/nodes/SoPolygonOffset\&.h>\fP
.PP
Inherits \fBSoNode\fP\&.
.SS "Public Types"

.in +1c
.ti -1c
.RI "enum \fBStyle\fP { \fBFILLED\fP = SoPolygonOffsetElement::FILLED, \fBLINES\fP = SoPolygonOffsetElement::LINES, \fBPOINTS\fP = SoPolygonOffsetElement::POINTS }"
.br
.in -1c
.SS "Public Member Functions"

.in +1c
.ti -1c
.RI "virtual \fBSoType\fP \fBgetTypeId\fP (void) const "
.br
.RI "\fIReturns the type identification of an object derived from a class inheriting \fBSoBase\fP\&. This is used for run-time type checking and 'downward' casting\&. \fP"
.ti -1c
.RI "\fBSoPolygonOffset\fP (void)"
.br
.ti -1c
.RI "virtual void \fBdoAction\fP (\fBSoAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBcallback\fP (\fBSoCallbackAction\fP *action)"
.br
.ti -1c
.RI "virtual void \fBGLRender\fP (\fBSoGLRenderAction\fP *action)"
.br
.in -1c
.SS "Static Public Member Functions"

.in +1c
.ti -1c
.RI "static \fBSoType\fP \fBgetClassTypeId\fP (void)"
.br
.ti -1c
.RI "static void \fBinitClass\fP (void)"
.br
.in -1c
.SS "Public Attributes"

.in +1c
.ti -1c
.RI "\fBSoSFFloat\fP \fBfactor\fP"
.br
.ti -1c
.RI "\fBSoSFFloat\fP \fBunits\fP"
.br
.ti -1c
.RI "\fBSoSFBitMask\fP \fBstyles\fP"
.br
.ti -1c
.RI "\fBSoSFBool\fP \fBon\fP"
.br
.in -1c
.SS "Protected Member Functions"

.in +1c
.ti -1c
.RI "virtual const \fBSoFieldData\fP * \fBgetFieldData\fP (void) const "
.br
.ti -1c
.RI "virtual \fB~SoPolygonOffset\fP ()"
.br
.in -1c
.SS "Static Protected Member Functions"

.in +1c
.ti -1c
.RI "static const \fBSoFieldData\fP ** \fBgetFieldDataPtr\fP (void)"
.br
.in -1c
.SS "Additional Inherited Members"
.SH "Detailed Description"
.PP 
The \fBSoPolygonOffset\fP class is a node type for 'layering' rendering primitives\&.
.PP
A common problem with realtime 3D rendering systems is that rendered primitives which are at approximately the same depth with regard to the camera viewpoint will appear to flicker\&. I\&.e\&.: from one angle one primitive will appear to be closer, while at another angle, another primitive will appear closer\&. When this happens, the rendered graphics at that part of the scene will of course look a lot less visually pleasing\&. 

One common situation where this problem often occurs is when you attempt to put a wireframe grid as an outline on top of filled polygons\&.
.PP
The cause of the problem described above is that the Z-buffer of any render system has a limited resolution, often at 16, 24 or 32 bits\&. Because of this, primitives which are close will sometimes get the \fIsame\fP depth value in the Z-buffer, even though they are \fInot\fP actually at the same depth-coordinate\&.
.PP
To rectify the flickering problem, this node can be inserted in the scene graph at the proper place(s) to explicitly define how polygons, lines and/or points should be offset with regard to other primitives\&.
.PP
As for the details of how the \fBSoPolygonOffset::factor\fP and \fBSoPolygonOffset::units\fP should be set, we quote the OpenGL documentation:
.PP
.PP
.nf
    The value of the offset is

        factor * DZ + r * units

    where DZ is a measurement of the change in depth relative to the
    screen area of the polygon, and r is the smallest value that is
    guaranteed to produce a resolvable offset for a given
    implementation. The offset is added before the depth test is
    performed and before the value is written into the depth buffer..fi
.PP
.PP
One word of notice with regard to the above quote from the OpenGL documentation: it doesn't really make sense to set 'factor' and 'units' to values with different signs, i\&.e\&. 'factor' to a negative value and 'units' to a positive value, or vice versa\&.
.PP
The pixels would then be 'pushed back' in z-order by one part of the equation, but at the same time be 'pushed forward' by the other part of the equation\&. This would most likely give very inconsistent results, but which may at first look ok\&.
.PP
We mention this potential for making a mistake, as it seems to be a quite common error\&.
.PP
Below is a simple, correct usage example:
.PP
.PP
.nf
#Inventor V2.1 ascii

Separator {
   Coordinate3 { point [ -1 -1 0, 1 -1 0, 1 1 0, -1 1 0 ] }
   
   Separator {
      BaseColor { rgb 1 1 0 }
      # needs to draw polygons-as-line, and not "real" lines -- see
      # documentation below on why this is so:
      DrawStyle { style LINES }
      # draw two triangles, to get a line crossing the face of the
      # polygon:
      IndexedFaceSet { coordIndex [ 0, 1, 2, -1, 0, 2, 3 -1 ] }
   }
   
   PolygonOffset {
      styles FILLED
      factor 1.0
      units 1.0
   }
   
   BaseColor { rgb 0 0.5 0 }
   FaceSet { numVertices [ 4 ] }
}
.fi
.PP
.PP
Without the polygonoffset node in the above example, the lines may look irregularly stippled with some graphics card drivers, as parts of it will show through the faceset, others not\&. This happen on seemingly random parts, as the z-buffer floating point calculations will be fickle with regard to whether or not the polygon or the line will be closer to the camera\&.
.PP
See the API documentation of the \fBSoPolygonOffset::styles\fP field below for a discussion of one important limitation of OpenGL's Z-buffer offset mechanism: it only works with polygons or polygons rendered in line or point mode, using the \fBSoDrawStyle::style\fP field\&.
.PP
\fBFILE FORMAT/DEFAULTS:\fP 
.PP
.nf
PolygonOffset {
    factor 1
    units 1
    styles FILLED
    on TRUE
}

.fi
.PP
.PP
\fBSince:\fP
.RS 4
TGS Inventor 2\&.5 
.PP
Coin 1\&.0 
.RE
.PP

.SH "Member Enumeration Documentation"
.PP 
.SS "enum \fBSoPolygonOffset::Style\fP"
Enumeration of the rendering primitives which can be influenced by an \fBSoPolygonOffset\fP node\&. 
.SH "Constructor & Destructor Documentation"
.PP 
.SS "SoPolygonOffset::SoPolygonOffset (void)"
Constructor\&. 
.SS "SoPolygonOffset::~SoPolygonOffset ()\fC [protected]\fP, \fC [virtual]\fP"
Destructor\&. 
.SH "Member Function Documentation"
.PP 
.SS "\fBSoType\fP SoPolygonOffset::getTypeId (void) const\fC [virtual]\fP"

.PP
Returns the type identification of an object derived from a class inheriting \fBSoBase\fP\&. This is used for run-time type checking and 'downward' casting\&. Usage example:
.PP
.PP
.nf
void foo(SoNode * node)
{
  if (node->getTypeId() == SoFile::getClassTypeId()) {
    SoFile * filenode = (SoFile *)node;  // safe downward cast, knows the type
  }
}
.fi
.PP
.PP
For application programmers wanting to extend the library with new nodes, engines, nodekits, draggers or others: this method needs to be overridden in \fIall\fP subclasses\&. This is typically done as part of setting up the full type system for extension classes, which is usually accomplished by using the pre-defined macros available through for instance \fBInventor/nodes/SoSubNode\&.h\fP (SO_NODE_INIT_CLASS and SO_NODE_CONSTRUCTOR for node classes), Inventor/engines/SoSubEngine\&.h (for engine classes) and so on\&.
.PP
For more information on writing Coin extensions, see the class documentation of the toplevel superclasses for the various class groups\&. 
.PP
Implements \fBSoBase\fP\&.
.SS "const \fBSoFieldData\fP * SoPolygonOffset::getFieldData (void) const\fC [protected]\fP, \fC [virtual]\fP"
Returns a pointer to the class-wide field data storage object for this instance\&. If no fields are present, returns \fCNULL\fP\&. 
.PP
Reimplemented from \fBSoFieldContainer\fP\&.
.SS "void SoPolygonOffset::doAction (\fBSoAction\fP *action)\fC [virtual]\fP"
This function performs the typical operation of a node for any action\&. 
.PP
Reimplemented from \fBSoNode\fP\&.
.SS "void SoPolygonOffset::callback (\fBSoCallbackAction\fP *action)\fC [virtual]\fP"
Action method for \fBSoCallbackAction\fP\&.
.PP
Simply updates the state according to how the node behaves for the render action, so the application programmer can use the \fBSoCallbackAction\fP for extracting information about the scene graph\&. 
.PP
Reimplemented from \fBSoNode\fP\&.
.SS "void SoPolygonOffset::GLRender (\fBSoGLRenderAction\fP *action)\fC [virtual]\fP"
Action method for the \fBSoGLRenderAction\fP\&.
.PP
This is called during rendering traversals\&. Nodes influencing the rendering state in any way or who wants to throw geometry primitives at OpenGL overrides this method\&. 
.PP
Reimplemented from \fBSoNode\fP\&.
.SH "Member Data Documentation"
.PP 
.SS "\fBSoSFFloat\fP SoPolygonOffset::factor"
Offset multiplication factor\&. Scales the variable depth in the z-buffer of the rendered primitives\&.
.PP
See \fBSoPolygonOffset\fP's main class documentation above for detailed information on how the factor value is used\&.
.PP
Default value is 1\&.0\&. 
.SS "\fBSoSFFloat\fP SoPolygonOffset::units"
Offset translation multiplication factor\&. Will be multiplied with the value which represents the smallest discrete step that can be distinguished with the underlying Z-buffer resolution\&.
.PP
See \fBSoPolygonOffset\fP's main class documentation above for detailed information on how the units value is used\&.
.PP
Note that positive values will push geometry 'away' into the Z-buffer, while negative values will 'move' geometry closer\&.
.PP
Default value is 1\&.0\&. 
.SS "\fBSoSFBitMask\fP SoPolygonOffset::styles"
The rendering primitive type to be influenced by this node\&. This is a bitmask variable, so you can select several primitive types (out of filled polygons, lines and points) be influenced by the offset at the same time\&.
.PP
There is one very important OpenGL limitation to know about in this regard: Z-buffer offsetting can \fIonly\fP be done for either polygons, or for \fIpolygons\fP rendered \fIas\fP \fIlines\fP or \fIas\fP \fIpoints\fP\&.
.PP
So attempts at using this node to offset e\&.g\&. \fBSoLineSet\fP / \fBSoIndexedLineSet\fP or \fBSoPointSet\fP primitives will \fInot\fP work\&.
.PP
See the comments in the scene graph below for a detailed example on what \fBSoPolygonOffset\fP can and can not do:
.PP
.PP
.nf
#Inventor V2\&.1 ascii

Separator {
   # render polygon:

   Coordinate3 { point [ -1\&.1 -1\&.1 0, 1\&.1 -1\&.1 0, 1\&.1 1\&.1 0, -1\&.1 1\&.1 0 ] }
   BaseColor { rgb 0 0\&.5 0 }
   FaceSet { numVertices [ 4 ] }

   # offset polygon-as-lines to be in front of above polygon:

   PolygonOffset {
      styles LINES
      factor -2\&.0
      units 1\&.0
   }
   
   # render lines:

   Coordinate3 { point [ -1 -1 0, 1 -1 0, 1 1 0, -1 1 0 ] }
   BaseColor { rgb 1 1 0 }

   Switch {
      # change this to '0' to see how glPolygonOffset() does *not* work
      # with "true" lines
      whichChild 1

      DEF child0 Group {
         # can *not* be offset
         IndexedLineSet { coordIndex [ 0, 1, 2, 3, 0, 2, -1, 1, 3 -1 ]
         }
      }

      DEF child1 Group {
         # will be offset
         DrawStyle { style LINES }
         FaceSet { numVertices [ 4 ] }
      }
   }
}
.fi
.PP
.PP
Field default value is SoPolygonOffset::FILLED\&. 
.SS "\fBSoSFBool\fP SoPolygonOffset::on"
Whether the offset is on or off\&. Default is for \fBSoPolygonOffset::on\fP to be \fCTRUE\fP\&. 

.SH "Author"
.PP 
Generated automatically by Doxygen for Coin from the source code\&.