Jump to content

Recommended Posts

This operator allows you to call a collection of nodes on any data or simply no data (generators). It gives you full control over how the lambda function should be run.

 

  • Like 6

Share this post


Link to post
Share on other sites

I'm not sure how I'd use this, or what organization I'd need to take advantage of it fully.

However, after taking a peek into your other videos, the rest of your work is pretty mind blowing.

  • Like 1

Share this post


Link to post
Share on other sites

This looks awesome :)

But isn't this sort of what the invoke sop does?
although that does have the constraint that you need to call a compiled block (with all the constraints of that)

  • Like 1

Share this post


Link to post
Share on other sites

Thanks a lot guys, appreciate the feedback. Let me address your questions, starting with @acey195 because it's easier :D

I see the Lambda SOP as a high level tool that uses the Invoke SOP internally, but both approaches require compilable networks.

The key differences between this and the low-level Invoke is:

1. This is easier and quicker to use, drag and drop, plug and play. With Invoke SOP you have to prepare your network in compilable enclosure, name your compile inputs properly so invoke can see them, etc.

2. It provides a nice way to gather everything nicely in a subnet just like a template, where all the nodes are centralized inside. You can do this yourself also of course.

3. It provides all the looping options of a regular For Loop block. I think being able to invoke a collection of nodes once, is very useful, but one should also have the ability to run the same operation in a loop. Sure you can make your own loop each time, but I see this part of a common workflow.

4. I also provide an additional looping mode which allows running over attributes. It would be nice if this was actually built into the For Loop blocks because it takes a bit of setup to get it right and optimized.

Because it's a common operation I have needed in production many times before. For example, let's say you have some geometry you are deforming, i.e. using Path Deform, but you might also have rest positions for the same geometry, and other attributes where you also want them to have the same deformations. The common approach is to copy each of these attributes into P separately (or whatever else you are modifying) and then apply the same nodes to the new P and then copy the result back into the original attribute, and then copy this attribute back into the main branch.

This is a lot of work to do. Run Over Attributes does this in a loop.

5. Run Over Attributes also makes every SOP, attribute agnostic in a way. For example, Bend SOP only works on P, but by using this mode, you can perform it on any attribute which either requires you to do the above trick or wait for SESI to expose the modified attribute as a parameter. I think this should also be intrinsic to Invoke to be able to invoke any operation on any attribute.

6. This operator reduces redundancy and increases readability of a scene, just like Invoke SOP, but on a greater scale and with greater control. If I am not wrong, Invoke SOP was introduced so SESI doesn't have to code the same operator both in DOPs and SOPs, which is why Detangle is a SOP. I don't know if they made it to also call a collection of nodes as a template in this manner.

I guess you can summarize it as "This operator invokes any number of operations on any number of arbitrary attributes over any geometry/element/number or no input at all, in a feedback or merge gather style."

Hope that makes sense.

Edited by pusat
  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×