Is it important to promote the number of threads parameter for digital

[magneto]

Hi,

I was thinking about this for a while. I see that some people promote the number of threads parameter if their asset's subnet includes VOPSOPs. I feel this is a functional choice and makes sense. But is this a good recommended practice?

Because I noticed SESI doesn't do it for the Match Axis operator. Mountain operator has it but that's because it's a VEX SOP.

I am sure there is some consensus on it among the masters though

[hopbin9]

Isn't that parameter only valid when the VEX SOP isn't compiled. When you compile it to a SOP type the parameter no longer can be changed.

[magneto]

I thought it was always effective. Do you mean in the case of Mountain SOP which is a VEX SOP (no subnet) or Match Axis SOP which is a subnet that has a VOPSOP inside?

When I change the number of threads in each, the cook time changes.

[hopbin9]

Don't exactly know, but you can put a VOP SOP inside an asset.

You can also compile a VOP SOP to a SOP asset. So that it no longer has to be compiled, and when you do that only the VOP parameters appear in the parameter rollout. I think the thread option is no longer shown.

Of course, I could be wrong. I'm to lazy to try it right now.

Edited September 11, 2012 by hopbin9

[magneto]

I never seen compiled VOP assets. What's the advantage of that? I am not sure how the VEX compiler works exactly but I thought there is a virtual machine that runs the code so could potentially make optimizations based on the machine running the asset?

Also how do you compile it just out of curiosity?

[old school]

A compiled VOP asset is a simple VOP network that has been turned in to a compiled SOP asset or VOP asset.

If you take any VOP SOP and RMB on the tile, you have two options:

"Compile VEX code to Sop Type..."

or

"Compile VEX code to Vop Type..."

Both options are self-explanatory.

Why would you do this?

So you don't have to compile the code over again with multiple instances in the current scene file and all the other re-usability features you get with HDA's.

What is the advantage to compiling a VOP network directly to a SOP over Subnet SOP encapsulated VOP network?

The directly compiled VOP network will be lighter. If you expect to use the VOP network a lot and there is no SOP wrapper required to add additional functionality, just compile it directly in to a SOP.

Be forewarned though. KEEP THE HIP FILE AROUND WITH THE VOP NETWORK that was used to compile the SOP HDA directly. Unlike compiled VOP materials that keep their VOP network around (as of Houdini 11), the method of compiling SOPs from VOPs doesn't. That is unless you like to edit the raw VEX code encapsulated in the HDA.

[magneto]

Thanks old school, that makes a lot of sense. I had the impression that the compiled VOPs would be slower because of the VEX virtual machine not being able to optimize based on the running machine. I guess VEX VM doesn't do those kind of optimizations.

[hopbin9]

I never seen compiled VOP assets. What's the advantage of that? I am not sure how the VEX compiler works exactly but I thought there is a virtual machine that runs the code so could potentially make optimizations based on the machine running the asset?

Also how do you compile it just out of curiosity?

Compiling VEX to asset types greatly reduces cooking times for your HIP scene. This can improve both the load times of a HIP file and render times.

If you'd like to see the difference. Create a subnet, put inside it a sphere and a material network. In the material network create a basic Material Shader Builder material, and assign it to the sphere. Turn the subnet into an asset, and then create 10 copies of that asset. Reload the scene and render a few frames. Next, unlock that asset and go to the material. Right click, and Compile VEX code to Shop Type. Drop the new material asset and tell the sphere to use that. Lock the asset and update. It'll load 10 times faster and renders will start up faster.

[magneto]

Thanks hopbin will try that. Pretty good feature