VertexConstraint

199 views
Skip to first unread message

Daniele Dolci

unread,
May 20, 2018, 8:51:35 AM5/20/18
to Python Programming for Autodesk Maya
Hi, 

I built a rig whose speed is between 40 and 50 fps in playback. When I started to use follicles, even by using a low res driver, the speed goes down dramatically(to 10-15 fps in playback). Therefore I decided to give it a try to build my own node to create some kind of vertex constraint. The idea is to take in a mesh, the index of the vertex to attach the object to, and outputing the world position of the vertex. 

Unfortunately what I made is even slower than maya's follicles, I was wondering if there is something obviously wrong I am doing or if that depends on the fact I used python rather than c++. I attach below the compute method of the deformer. If anyone could help to optimize it to speed it up would be great! 

    def compute(self, plug, data):
        input_geometry = data.inputValue(Vertstraint.input_mesh).asMesh()     
        fn_input_geometry = OpenMaya.MFnMesh(input_geometry)
        index = data.inputValue(Vertstraint.vertex).asFloat()

        vertex_position = OpenMaya.MPoint()
        fn_input_geometry.getPoint(int(index), vertex_position, OpenMaya.MSpace.kWorld)

        output = data.outputValue(Vertstraint.world_position)
        result = OpenMaya.MFloatVector(vertex_position.x, vertex_position.y, vertex_position.z)
        output.setMFloatVector(result)

        data.setClean(plug)


Cheers,
Daniele 

Alok Gandhi

unread,
May 20, 2018, 12:03:12 PM5/20/18
to python_in...@googlegroups.com
Generally, it is advised to use C++ for querying vertex data, python is definitely slower (than C++) at computing mesh data, especially when the data set is large.

You can further test by running this against a simple cube or sphere. You should see higher fps.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/67132225-b25f-4d24-a343-c14e41abcd1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
Message has been deleted

Daniele Dolci

unread,
May 20, 2018, 12:08:20 PM5/20/18
to Python Programming for Autodesk Maya
Hi, 

THanks for the reply. I am actually not querying all the vertices but only one vertex. Also, I am not using an high res mesh to do this but I have a low res driver with very few vertices, that is why I think i am doing something wrong in my code. 

Cheers,
Daniele 

Fuzes Marcell

unread,
May 20, 2018, 12:16:27 PM5/20/18
to python_in...@googlegroups.com
Hi,

The reason why Python nodes are going to slow down your rig is because they are "untrusted".
Meaning no other nodes will be evaluated while an instance of this node is evaluated.
So even if your Python code is well optimized it will slow down significantly your rig because every node has to wait for the Python node to evaluate before they can compute again.
This is happening because of the Global Interpeter Lock. 

You can read more about this in the Using Parallel Maya

Cheers

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

Daniele Dolci

unread,
May 20, 2018, 12:29:54 PM5/20/18
to Python Programming for Autodesk Maya
Hi,

Thanks for you reply. So do you think that if I wrote that exact same code in c++ it would be much faster? 

Cheers,
Daniele 

Justin Israel

unread,
May 20, 2018, 5:17:30 PM5/20/18
to python_in...@googlegroups.com


On Mon, May 21, 2018, 4:16 AM Fuzes Marcell <fuzes....@gmail.com> wrote:
Hi,

The reason why Python nodes are going to slow down your rig is because they are "untrusted".
Meaning no other nodes will be evaluated while an instance of this node is evaluated.
So even if your Python code is well optimized it will slow down significantly your rig because every node has to wait for the Python node to evaluate before they can compute again.
This is happening because of the Global Interpeter Lock. 

Is that really the case for all nodes or just for nodes implemented in Python? If it really is because of the GIL then I would think C++ nodes could continue to evaluate in Parallel. 

On 20 May 2018 at 18:08, Daniele Dolci <daniele...@gmail.com> wrote:
Hi, 

THanks for the reply. I am actually not querying all the vertices but only one vertex. Also, I am not using an high res mesh to do this but I have a low res driver with very few vertices, that is why I think i am doing something wrong in my code. 

Cheers,
Daniele 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CANC2f3QQL1dKrs86B_DG8os6ipMHkMrpXaqJ6qqHvaz2tJFYwg%40mail.gmail.com.

Justin Israel

unread,
May 20, 2018, 5:21:40 PM5/20/18
to python_in...@googlegroups.com


On Mon, May 21, 2018, 9:17 AM Justin Israel <justin...@gmail.com> wrote:


On Mon, May 21, 2018, 4:16 AM Fuzes Marcell <fuzes....@gmail.com> wrote:
Hi,

The reason why Python nodes are going to slow down your rig is because they are "untrusted".
Meaning no other nodes will be evaluated while an instance of this node is evaluated.
So even if your Python code is well optimized it will slow down significantly your rig because every node has to wait for the Python node to evaluate before they can compute again.
This is happening because of the Global Interpeter Lock. 

Is that really the case for all nodes or just for nodes implemented in Python? If it really is because of the GIL then I would think C++ nodes could continue to evaluate in Parallel. 

I just saw the definition in the Parallel doc about untrusted nodes. I will have to spend more time reading through this to understand why Python nodes are untrusted. 

Daniele Dolci

unread,
May 20, 2018, 5:27:00 PM5/20/18
to Python Programming for Autodesk Maya
For me it is not really clear indeed. Although I will try to rewrite it in c++.
In the meanwhile if you find anything useful please keep me posted.

Cheers,
Daniele

Fuzes Marcell

unread,
May 20, 2018, 5:36:40 PM5/20/18
to python_in...@googlegroups.com
I believe every node has to wait for the Python node.

But Raffaele has two great videos about Maya evaluation in which he also talks about why Python nodes should be avoided.
This is the time stamp where he specifically talks about Python nodes

These are the two videos in which he explains the Maya graph evaluation.

I highly recommend these videos as I think he does a good job at explaining everything!

Hope this helps!

Cheers

Cheers,
Daniele

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/0046a4ef-22d8-4962-a3a8-badc640cb5aa%40googlegroups.com.

Marcus Ottosson

unread,
May 20, 2018, 5:57:19 PM5/20/18
to python_in...@googlegroups.com

If you’d rather use an existing node to solve your problem, try selecting a vertex and hit Particles -> Emit from Object. It will create, amongst other things, a geoConnector which will provide you with the vertex position in worldspace. You can delete the other nodes and, optionally, recreate the node and its connections via Python if you’d rather skip the delete step.


On 20 May 2018 at 22:36, Fuzes Marcell <fuzes....@gmail.com> wrote:
I believe every node has to wait for the Python node.

But Raffaele has two great videos about Maya evaluation in which he also talks about why Python nodes should be avoided.
This is the time stamp where he specifically talks about Python nodes

These are the two videos in which he explains the Maya graph evaluation.

I highly recommend these videos as I think he does a good job at explaining everything!

Hope this helps!

Cheers
On 20 May 2018 at 23:27, Daniele Dolci <daniele...@gmail.com> wrote:
For me it is not really clear indeed. Although I will try to rewrite it in c++.
In the meanwhile if you find anything useful please keep me posted.

Cheers,
Daniele

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

Daniele Dolci

unread,
May 20, 2018, 6:39:45 PM5/20/18
to Python Programming for Autodesk Maya
Hi,

I know Raffaele videos, already watched them, I don't remember the part about python nodes though. Will watch again.

Is the geo connector faster than follicle?

Cheers,
Daniele

AK Eric

unread,
May 21, 2018, 12:48:05 AM5/21/18
to Python Programming for Autodesk Maya
Having been in touch with the Autodesk devs directly, I no longer use any Python-base scripted-plugin-based nodes since Maya 2015 (Maya 2016 introduced the multithreaded evaluation graph):  Per discussion above, from 2016-on, they've confirmed (and I've seen first hand) they drop the evaluation graph back to a single thread during evaluation (which you can confirm for yourself by profiling the evaluation of your rig), based on Python's GIL : I still make scripted plugin based commands, they're fine.  But if you want a performant plugin-based node, you needs to be making it via the c++'s.  

BTW, this makes me personally sad since I love Python, but I completely understand the reason behind it: Python as Maya implements it simply isn't multithreaded.

Marcus Ottosson

unread,
May 21, 2018, 1:33:46 AM5/21/18
to python_in...@googlegroups.com

Is the geo connector faster than follicle?

You tell me!

Per discussion above, from 2016-on, they’ve confirmed (and I’ve seen first hand) they drop the evaluation graph back to a single thread during evaluation (which you can confirm for yourself by profiling the evaluation of your rig)


On 21 May 2018 at 05:48, AK Eric <war...@sbcglobal.net> wrote:
Having been in touch with the Autodesk devs directly, I no longer use any Python-base scripted-plugin-based nodes since Maya 2015 (Maya 2016 introduced the multithreaded evaluation graph):  Per discussion above, from 2016-on, they've confirmed (and I've seen first hand) they drop the evaluation graph back to a single thread during evaluation (which you can confirm for yourself by profiling the evaluation of your rig), based on Python's GIL : I still make scripted plugin based commands, they're fine.  But if you want a performant plugin-based node, you needs to be making it via the c++'s.  

BTW, this makes me personally sad since I love Python, but I completely understand the reason behind it: Python as Maya implements it simply isn't multithreaded.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

Justin Israel

unread,
May 21, 2018, 1:46:38 AM5/21/18
to python_in...@googlegroups.com


On Mon, May 21, 2018, 4:48 PM AK Eric <war...@sbcglobal.net> wrote:
Having been in touch with the Autodesk devs directly, I no longer use any Python-base scripted-plugin-based nodes since Maya 2015 (Maya 2016 introduced the multithreaded evaluation graph):  Per discussion above, from 2016-on, they've confirmed (and I've seen first hand) they drop the evaluation graph back to a single thread during evaluation (which you can confirm for yourself by profiling the evaluation of your rig), based on Python's GIL : I still make scripted plugin based commands, they're fine.  But if you want a performant plugin-based node, you needs to be making it via the c++'s.  

BTW, this makes me personally sad since I love Python, but I completely understand the reason behind it: Python as Maya implements it simply isn't multithreaded.

Python as CPython implements it simply isn't multithreaded ;-) 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/ce992caf-1964-4e7d-a96d-b126c8e5a923%40googlegroups.com.

Justin Israel

unread,
May 21, 2018, 1:52:14 AM5/21/18
to python_in...@googlegroups.com


On Mon, May 21, 2018, 5:46 PM Justin Israel <justin...@gmail.com> wrote:


On Mon, May 21, 2018, 4:48 PM AK Eric <war...@sbcglobal.net> wrote:
Having been in touch with the Autodesk devs directly, I no longer use any Python-base scripted-plugin-based nodes since Maya 2015 (Maya 2016 introduced the multithreaded evaluation graph):  Per discussion above, from 2016-on, they've confirmed (and I've seen first hand) they drop the evaluation graph back to a single thread during evaluation (which you can confirm for yourself by profiling the evaluation of your rig), based on Python's GIL : I still make scripted plugin based commands, they're fine.  But if you want a performant plugin-based node, you needs to be making it via the c++'s.  

BTW, this makes me personally sad since I love Python, but I completely understand the reason behind it: Python as Maya implements it simply isn't multithreaded.

Python as CPython implements it simply isn't multithreaded ;-) 

To be fair, this joke only works if it reads as "parallel" (vs concurrent) instead of multithreaded 

Angelo Sta. Catalina

unread,
May 21, 2018, 9:07:27 AM5/21/18
to python_in...@googlegroups.com
You cant attach anything to a vertex without loosing GPU parallel functionality. Maya sends calculation data to display the geometry to the GPU. GPU then sends it to your monitor. When you attach anything to a piece of geo, it has to be calculated in the CPU. When this happens, Maya automatically disables GPU functionaliity. This might be what is going on with your rigs

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

Daniele Dolci

unread,
May 21, 2018, 9:12:55 AM5/21/18
to Python Programming for Autodesk Maya
Hi,

This is why I created a low res driver and I have hidden it from the viewport. if both the low res driver and the controls are hidden, only the high res mesh will be evaluated. 

 

Angelo Sta. Catalina

unread,
May 21, 2018, 9:14:07 AM5/21/18
to python_in...@googlegroups.com
With GPU, even hidden meshes are evaluated.

On Mon, May 21, 2018, 8:12 AM Daniele Dolci <daniele...@gmail.com> wrote:
Hi,

This is why I created a low res driver and I have hidden it from the viewport. if both the low res driver and the controls are hidden, only the high res mesh will be evaluated. 

 

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_m...@googlegroups.com.

AK Eric

unread,
May 21, 2018, 6:22:04 PM5/21/18
to Python Programming for Autodesk Maya
"Python as CPython implements it simply isn't multithreaded ;-) "

Right, I should have been more specific ;)
Reply all
Reply to author
Forward
0 new messages