Hi!

So I've run into an issue at work when trying to compile a foreach operation. I've created a point attribute called “offset” which runs from -100 to 100 on a grid.
That gets piped into a copytopoints sop, where I'm copying a sphere to each point on the grid.
Then with a simple sin expression, I'm translating the spheres with the offset. Except when I have “Enable Compiling” turned ON, the offset doesn't work. With it OFF, the offset works.. but then it's not compiled.

I've attached the scene file. What's going on here?

Thanks,
Colby

The Transform SOP, transform_with_offset needs to recook on every iteration of the loop, so it needs to be inside the loop.

Also, inside a compiled block, in order to refer to a node that isn't a regular input, you have to add it as a “spare input”, using “Add Spare Input” in the gear menu, then selecting the node for “Spare Input 0”. Any expressions that refer to that spare input need to use a number that is -1 minus the spare input number, (so -1 for spare input 0, -2 for spare input 1, etc.)

Lastly, you can't use expression local variables in compiled blocks, so you have to remove the $CEX, $CEY, $CEZ from the Transform SOP pivot. Edit: You should be able to use the centroid expression function [www.sidefx.com] if you need the same sort of behaviour, though the pivot can be anything if you just have translations.

After that, it seems to work okay, (see attached).

That's it! Really helpful. Definitely some gotchas in there.

I do have another question that expands upon your answer: why is it significantly slower when I check on “Mutlithreaded when Compiled” on the Block End node?

I thought maybe it'd scale well but I don't think that's the case. Comparing the results with Multithreaded when Compiled ON vs OFF always results in slower performance with this scene. Any ideas?

Colby

In Houdini 16.0, the point(-1, ) function will lock unnecessarily. So if the total amount of work being done elsewhere is minimal, this lock can cause many cores to start to stumble over each other. On my 6-core, 12-thread machine I see the multithreaded running 2x faster than single-threaded. But perhaps you have more cores in your machine?

I get faster performance when “Multithread when Compiled” is on (~13ms/frame playback) than when it's off (~22ms/frame playback).

Even better, if I remove the whole compiled block, for loop, etc, and replace it with just a Copy and Transform that makes npoints("../grid2")copies of the sphere, then an Attribute Wrangle with the spheres in the input 0 and the points in input 1, with the code:


then it's about 4ms/frame to play it back, and most of that time isn't in cooking the SOP. In that case, it's taking advantage of the fact that on each frame, the only thing that happens is that the Attribute Wrangle changes P, so it knows that the topology doesn't change from frame to frame, and the viewport can update faster that way.

If you're planning to render the spheres, you can use disconnected points with pscale for the radius, instead of sphere primitives, and it'll be even faster and take up less memory.

This has also come up before…

https://www.sidefx.com/forum/topic/49364/ [www.sidefx.com]

Basically, if you have a dual socket system multithreading likely is running slower for you in 16.0. But the best option for simple examples like this is what Neil posted.