Resolution parameter in points3d is sometimes ignored

[JannickWeisshaupt]

With mayavi 4.5.1 and vtk 8.1.0 the resolution parameter in points3d is sometimes completely ignored. This is for example reproducible with test_molecule(). Whether it is ignored or not is determined at startup of the program and will then be consistent further on.

[adeak]

It sort of defeats the purpose of using a high-level API, but anyway there's a temporary workaround by simply setting the phi and theta resolutions manually on the underlying glyphs created by mlab. This seems to work consistently:

res = 25
points = mlab.points3d(X, Y, Z, S) # omitted resolution=res
points.glyph.glyph_source.glyph_source.phi_resolution = res
points.glyph.glyph_source.glyph_source.theta_resolution = res

[JannickWeisshaupt]

Thanks a lot. Your workaround works perfectly. Do you know what the underlying problem is that causes the resolution parameter to not work?

[adeak]

Unfortunately not; I'm pretty much an end user of mayavi.

That being said I took a peek at the source, and saw that points3d is actually a callable class constructed here. All relevant keywords are handled by methods of its parent class. As far as I can tell the specific factory that does the work is GlyphFactory, defined here. Again this class does very little and most of the work is in its parent class, VectorsFactory.

Now, there are handlers in this class which look like they're supposed to be called as callbacks, such as _resolution_changed. This method adjusts the appropriate resolutions for every kind of glyphs.

Since you've noted that the problem is intermittent, and either it works for a session or it doesn't, my best guess would be that whatever callback mechanism should be calling _resolution_changed doesn't work, due to some race condition or other Heisenbug-inducing scenario.

Also note these few lines:

# Workaround for different version of VTK:
if hasattr(v.glyph.glyph_source, 'glyph_source'):
    g = v.glyph.glyph_source
else:
    g = v.glyph

The above might suggest that depending on the version of VTK my workaround might not work; in those cases it's likely that one has to omit a .glyph_source lookup in each resolution:

points = mlab.points3d(X, Y, Z, S) # omitted resolution=res
points.glyph.glyph_source.phi_resolution = res
points.glyph.glyph_source.theta_resolution = res

I don't know whether or not this works and whether different VTK versions that would merit this change reproduce the original bug in the issue to begin with.

Also note that a similar check is not performed for _resolution changed:

def _resolution_changed(self):
    glyph = self._target.glyph.glyph_source.glyph_source # <- possible AttributeError?
    ...

I'm not intimately (or remotely, to be honest) familiar with the machinery of VTK, but this might be a bug in itself.

[prabhuramachandran]

I will check later this week and get back on this thread.

[prabhuramachandran]

I am unable to reproduce this. Could you try with the latest released version of mayavi and traits. I would also appreciate a tiny example so I am on the same page, this is what I used:

%gui qt
from mayavi import mlab
import numpy as np
x, y, z = np.random.random((3, 10))
mlab.points3d(x, y, z, resolution=20)
mlab.clf()
mlab.points3d(x, y, z, z, resolution=20)
mlab.clf()
mlab.points3d(x, y, z, z, resolution=40)

[JannickWeisshaupt]

My versions are:
python = 3.4
mayavi = 4.6.1
traits = 4.6.0
vtk = 8.1.1
i.e. traits and mayavi are up to date. The problem occurs whenever I use points3d e.g.

from mayavi import mlab
import numpy as np
x, y, z = np.random.random((3, 10))
mlab.points3d(x, y, z, z, resolution=40)
mlab.show()

suffices.

[adeak]

I've also been using a separate script executed directly with python, just like Jannick. I can reproduce the problem with that example. My versions are

• python 3.5.4
• mayavi 4.5.0
• traits 4.6.0
• vtk 8.0.0

As for me this is an older version where I compiled VTK by hand. I've been using python 3.6 (and recently 3.7) but I couldn't get mayavi working with an appropriate backend by just using pip, so I fell back on my old working install.

[prabhuramachandran]

I just tried with master on this example:

from mayavi import mlab
import numpy as np
x, y, z = np.random.random((3, 10))
g = mlab.points3d(x, y, z, z, resolution=10)
g.actor.property.representation = 'wireframe'
mlab.show()

The wireframe is to just see if it is changing and I changed resolution to 10, 20, 40 and it works as expected.

Am on MacOS, using probably traits from master at some point, traitsui, VTK 8.1.1 and mayavi from master. This is going to need more investigation to see where the issue is. Would it be possible to test this with Mayavi master? Thanks.

[JannickWeisshaupt]

With your example with the wireframe setting the bug is gone, i.e. the wireframe always has high resolution. If I use
g.actor.property.representation = 'surface'
the bug is also gone and the plot is as it is supposed to be.

[adeak]

@prabhuramachandran just to be sure we're on the same page, the problem is that plotting a points3d once with a given non-default resolution sometimes goes ignored, and the resulting plot has resolution=8. And running the same script a few times will show that in some cases the non-default resolution is set, but in others the resolution is stuck on default.

As for the above change killing the bug: is it possible that modifying the actor triggers a call to some updating/redrawing method that would otherwise not get called as per the bug?

[adeak]

OK, I've managed to install mayavi+vtk+pyqt5 for python 3.6. The issue we're discussing has gone away, but I'm now facing #656. Not exactly an improvement ;) Current versions:

• python 3.6.0
• mayavi 4.6.1
• traits 4.6.0
• vtk 8.1.1
• PyQt5 5.11.2

Using debian in case that matters.

As I understand it, there's not much use checking master, since the current issue is fixed with the update, and the rendering issue I see is unrelated to mayavi.

Update: what I see is actually the combination of the above issue and another one that is solved by #491 (comment). Even though I have no opacity set in the call, I see the weird sphere rendering in our test case which goes away with frontface_culling.

Update 2: while the problem I see seems to be the same, your suggested workaround with depth peeling doesn't seem to work for my case, not even with f.scene.renderer.maximum_number_of_peels = 0.