Documentation for vertexMC, normalMC, MCDCMatrix, MVCMatrix.

Development
1

Hi,
I am starting my shader development in VTK. Earlier, I had some knowledge on the built-in 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

2

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.

1 Like
3

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

4

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.

5

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)

6

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.