CODEWITHSUNDEEP
pythonvtkenthoughtmayavi
Sleepyhead
Sleepyhead

Reputation: 1021

Simple arrow mayavi/tvtk in mlab weird behaviour (looks like a bug)

I am trying to do a simple arrow in mlab to point to different areas on the graph. Consider this example:

fig = mlab.figure( bgcolor=(0, 0, 0))
b=visual.Box(x=0, y=10, z=10)
visual.set_viewer(fig)
b=visual.Box(x=0, y=10, z=10)
b2=visual.Box(x=10,y=10,z=10, color=(0,0,1))
a=visual.Arrow(x=10,y=10,z=10, color=(1,0,0))

So in my mind the arrow should appear from the blue box, however it lives it's own misterious life and is located absolutely off. That is very strange that boxes are located and bound to the grid (so if I put b to x=10,y=10,z=10 the two boxes will be collocated), however the arrow is not. This is what I see Is this a bug or a feature?

Update:

I was playing around trying to fix the above and found the behaviour of the arrow very weird. This is what I do (in ipython for interaction):

from mayavi import mlab
from tvtk.tools import visual
fig=mlab.figure( bgcolor=(0, 0, 0))
visual.set_viewer(fig)

First put the box somewhere on canvas as a reference:

b=visual.Box(x=10,y=4,z=1)

Then I want an arrow sticking out of the box:

a=visual.Arrow(x=10,y=4,z=1)

Didn't work out (same as the first part of the question):

Arrow_error

Now, let's change length of the cone without reason

a.length_cone

returns

0.35

Let's change it

a.length_cone=0.5

Now the arrow is sticking out of the box as it should be Arrow_error

Change length of the cone back to 0.35 to see if this changes the arrow back to wrong position

a.length_cone=0.35

No, the arrow stays in the box where it should be. This looks like a bug.

Upvotes: 1

Views: 3135

Answers (3)

Alex V.
Alex V.

Reputation: 456

I have a similar scenario and as far as I can see, using quiver3d is the best option so far, because it gives me a lot of options regarding the arrow style. I use:

x, y, z = 0, 0, 0
u, v, w = 1, 0, 0
v = mlab.quiver3d(x, y, z, u, v, w, mode='arrow')
v.glyph.glyph.clamping = False

The clamping ensures that the arrow actually has the length that you specify. If you don't use it, the minimum length of the arrow will be one unit, no matter how short it was supposed to be.

Upvotes: 0

Sleepyhead
Sleepyhead

Reputation: 1021

Playing around with arrow, I wrote the following function to generate an arrow from x1,y1,z1 to x2,y2,z2

def Arrow_From_A_to_B(x1, y1, z1, x2, y2, z2):
    ar1=visual.arrow(x=x1, y=y1, z=z1)
    ar1.length_cone=0.4

    arrow_length=np.sqrt((x2-x1)**2+(y2-y1)**2+(z2-z1)**2)
    ar1.actor.scale=[arrow_length, arrow_length, arrow_length]
    ar1.pos = ar1.pos/arrow_length
    ar1.axis = [x2-x1, y2-y1, z2-z1]
    return ar1

Upvotes: 3

aestrivex
aestrivex

Reputation: 5280

Seems like ArrowSource doesn't allow for arrows extending beyond a short distance. It doesn't seem very useful at all. mlab functions like quiver3d return glyphs based on PolyDataSource instead.

This will plot two boxes and an arrow between them. I'm not sure if there's a simple way to do it with quiver3d which is definitely based off of PolyDataSource but may not have the same structure somehow.

b1=visual.Box()
b2=visual.Box(x=10)
v=mlab.pipeline.vectors(mlab.pipeline.vector_scatter(0,0,0,10,0,0)) #xyzuvw
v.glyph.glyph.clamping=False

Also, the behavior you encountered with ArrowSource doesn't seem like a bug, it's more like a minor feature that wasn't really developed.

Upvotes: 1

Related Questions