Fighting the architecture?

[jdj]

Hello board

Thought I'd ask you guys if you know if what I am trying to do is violating the Maya architecture or not. I have not explicitly seen any big don'ts about this setup but on the other hand something weird is going on.

I have made two custom nodes, the first one ("modifier") takes a polymesh as input ("inMesh") and returns a polymesh as output ("outMesh"). It interacts with the second node ("tester") through two attributes called "testOut" and "feedbackIn" (which is an array attribute).

The "tester" node then has amongst others two corresponding attributes called "testIn" and "feedbackOut".

The basic connections are quite obvious: polymesh to "modifier.inMesh", a shape node connected to "modifier.outMesh" and "modifier.testOut" to "tester.testIn" and "tester.feedbackOut" to "modifier.feedbackIn[0]".

Attribute affects for the "modifier" node are:
inMesh -> outMesh
inMesh -> testOut
feedbackIn -> outMesh

..and for the "tester" node:

testIn -> feedbackOut

So far so good.

Inside the "modifier" node, there is an iterative test & modify algorithm that tests points by setting the "testOut" attribute and requesting the "feedbackIn" result a specific number of times.

Prolem is that this setup is acting a bit strange. After some time testing I found out that unless I disable the cache on the attributes in the test / feedback loop with calls to myAttr.setCached(false); in the initialize() functions, the feedback loop always gives the same results - the first solution.

That made me a bit suspicious.

Next when I had got it working and congratulated myself over the results , I connected one more tester node to the "modifier.feedbackIn[1]" and got very strange results back in.

This made me ever more suspicious.

I just wonder if any of you guys know if this design is violating Maya's architecture ?

I can of course extract the testing code from the test object and integrate into the modifier node and I would be fine, but I do think that the setup above is cleaner as I can then derive different tester objects without having to touch the modifier, so I do want to try to get it working.

Any thoughts?

Cheers!
/ Daniel

[joojaa]

A node only computes if theres some output that need the data!

[jdj]

Hi Jojaa

Yes of course - that is what the attributeAffects loop is designed to do:

• modifier.testOut is connected to test.testIn
• test.testIn affects test.feedbackOut
• test.feedbackOut is connected to modifier.feedbackIn

In the iteration loop I set the modifier.testOut and queries the modifier.feedbackIn - that should according to all I know trigger test::compute() to evaluate and update the test.feedbackOut attribute. I do this loop several times during each evaluation of the modifier node.

I will further faulttrace this but I wonder if Maya perhaps is not designed to re-evaluate a plug several times during the same evaluation cycle.

I have suspicions in that direction since if I turn on the cache for any of these attributes, I always get the results of the first iteration back. Perhaps it is some kind of infinite-loop protection that my algorithm triggers?

...just some thoughts and I wonder if any of you know about such a thing.

Best regards
/ Daniel

[jdj]

Hi again

I have finally got it working!

I still believe that Maya has issues with this iterative test loop I use, because I need to disable all caches for the attributes in the loop in order for it to work.

However I made a change to the attribute setup and made a modifier.test compound array attribute instead containing the modifier.test[].testOut and modifier.test[].feedbackIn attrbutes. I needed to disable the cache on this compound attribute as well to get it working.

Now I do get cycle warnings and I guess that is fair enough - I can turn them off

Anyhow. It works and I am happy. The larger question however is still if this violates the Maya architecture... ah well.

Best regards
/ Daniel

[joojaa]

cycles are perfectly legal taht why its a warning, however the marking of dirty would not nesseserily operate in a timely and predictable fashion.

[deane]

How are you setting the value of 'testOut' in your iterative loop? Are you doing it with an MDataHandle or an MPlug?

Values set through MDataHandles do not do dirty bit propagation, meaning that once the first result has been calculated, subsequent changes will not force a recompute.

Values set through MPlugs do do dirty bit propagation. There is a performance penalty, however, possibly because the DG needs to restart evaluation, or perhaps because datablocks need to be recreated. Not sure.

[jdj]

Thank you deane

Great - that must be the issue! I do indeed use an MDataHandle and I was not aware of this behaviour.

Thank you
/ Daniel

[joojaa]

Id bet its because the DG needs to restart evaluation!

[mfiorilli]

Hi there,

I'm trying to do the exact same thing but I can't get it to work. Could you please provide more details on how you did it?

I'm having two nodes (two deformers). Let's called them "A" and "B".
"A" comes before "B" in the deformation order.
An attribute is connected from "B" to "A" in order to trigger "A" to recompute and cause a cycle (that's what I want).

In the compute part, "B" change his own trigger attribute via a mplug, and this attribute is connected to "A". But it won't refresh it.

Thanks.