Hi,
I am starting my shader development in VTK. Earlier, I had some knowledge on the builtin vertex shader variables like gl_ModelViewMatrix. However, those variables are no longer appearing valid in my python based VTK shader code. I think the new ones are vertexMC, normalMC, MCDCMatrix, MVCMatrix. etc. The problem is I could not find any good documentation or examples to understand these variables. Can someone help me in understanding these variable or point me to some relevant documentation.
Thanks
Hello,
Every input variables are suffixed with its reference frame, so vertexMC
means vertex
in ModelCoordinates
.
All the matrices are the transformation matrix from a reference to another: MCDCMatrix
means ModelCoordinates to DeviceCoordinates matrix
.
Here is the full list:

MC
: Model coordinates 
WC
: World coordinates 
VC
: View coordinates 
DC
: Device coordinates
So, the equivalent of gl_ModelViewMatrix
is MCVCMatrix
.
Hello
After upgrading to VTK 9.0.1 vertexMC is behaving differently. It seems the values of this variable are constrained and beyond those constraints the values are no longer equal to the values of the vertex defined in python. Is there a new way to use vertexMC? Are there some new major changes also for MCDCMatrix, MCVCMatrix, etc.?
Thanks
I have noticed similar strange behavior when upgraded to VTK 9.0.1. As you say vertexMC values seem clipped or something strange is going on between vertexMC that changed from VTK 8.1.2 to 9.0.1.
You can replicate this by drawing a simple square and trying to position it close to the origin (0, 0, 0) or far from the origin (e.g. (20, 0., 0)) then you will see vertexMC values that at least to me do not make sense.
It’s probably related to the shift/scale method that is automatically applied to improve precision when the dataset is far from the origin.
You can try to disable it (See https://vtk.org/doc/nightly/html/classvtkOpenGLPolyDataMapper.html#ad9643c903c7145ca1a1bd08c8d605401)
Thanks, Michael! This seemed to solve the problem. I still have to run some tests to see how the precision changes when some objects are far from the origin. But so far this is solving the problem.