Hi,

I'm trying to implement a VEX SOP that needs to reuse information from the previous iteration of the code. Point clouds and in particular a pcunshaded loop combined with pcexport would be a perfect match for my goals, since the algorithm needs to mark points by their proxymity to the point being processed.

Unfortunately loops of pcunshaded seems to get stuck in an infinite loop in H11.

Is pcunshaded intended to work in SOP context or is it limited to SHOPs?

Thanks in advance
Mate

Hi Mate,

Loops of pcunshaded() should not loop forever in H11 as long as you are shading each point with pcexport(). If you don't shade each point, the loop will continue returning the unshaded points. pcunshaded() is supported in both SOPs and SHOPs. Can you post a simplified hip file that demonstrates the infinite looping? Is this a hip file that worked in H10 but does not work in H11?

Thanks,
–Ian

Hi Ian,

thanks for your answer, which explained the infinite loop behavior. My code wasn't prepared to shade all the points.

The implication of this is that I can't use pcunshaded for my task. I would use pciterate instead of it, but I don't know how to check that a point is shaded or not instide a pciterate loop.

Is that possible?

Mate

ps.: Of course I will send the hip file, but first I would like to understand the possibilities and limitations. Maybe I misuse this whole thing.

Hi Mate,

pcunshaded() is designed to shade all the points returned by a query (pcopen(), pcopenlod(), etc). Typically, you'll do your query, shade the un-shaded points returned by the query, and then iterate over the points:


int handle = pcopen(…);

while (pcunshaded(handle, “MyChannel”))
{
rval = pcexport(…); // save channel data
}

while (pciterate(handle))
{
rval = pcimport(…); // import channel data
}


The advantage of this approach is that you only shade points returned by your queries, which may be less than the total number of points in the point cloud. If you don't pcexport() a value for each point in your point cloud, those points will essentially have undefined values (unless we guarantee they are initialized to zero, I forget). So my question to you is, why do you wish to do this? Can you just pcexport() a value of zero?

Thanks,
–Ian

Hi Ian,

I'm trying to implement a dart throwing algorithm for variable radius darts. The idea is that we put down a lot of points and then mark them for deletion, based on their radius. With this setup we can use point clouds for fast proximity queries.

I attached the hip file of the current state. The vex code is in ‘/obj/grid_object/DARTS_STATE’. I found an answer to my previous question, and now I'm using a separate pcunshaded loop for marking points as ‘pending’ before I iterate them in a pciterate loop. This way I can tell for sure if they are already processed or not.

It seems for me that the values of an unshaded channel is undefined, and not zero.

Thanks
Mate

Hi Mate,

You might want to have a look at the Physical SSS shader (hfs/houdini/vex/include/physicalsss.h: createPointCloud()). It uses a dart throwing algorithm to distribute points evenly over a surface. In H11, pcexport() takes an additional radius parameter that indicates the minimum separation distance between the point being exported and every other point in the point cloud. If the test fails, the point will not be exported. The idea is that the pcunshaded() loop continues until all points have been shaded and satisfy the distance requirement.

Thanks Ian for your help!

I will check the Physical SSS shader. Your answers helped me a lot!

Mate

Hi Ian,

thanks for the tip, from physicalsss.h I learned a lot, and probably will for a while. Unfortunately the DT algorithm implemented there is not working for me for several reasons. The main is that it supports only uniform radius darts, one other is that it depends on sample_geometry which is not working in SOPs.

Anyway, after reading that, I restarted from scratch, and since I already suspected a bug behind my misfortunes I started to rigorously test every step I made. The result is the attached hip file.

This is the most simple reproduction of the bug I could come up with. It's fairly simple, and it works perfectly until the point number of the point that has a bigger radius is between 0 and 255. Higher than that one or more pc* function starts to ‘leak’ and random points start to misbehave. At every n*256 n*256-1 boundary the amount of leakage increases with a discreet step. The interesting parameter is the group parameter of point1. Also by bypassing the sort1 node you can see how the leakage is dependent on point numbers.

I posted a bug report under the title: “Point cloud functions leak in SOP context”.

cheers
Mate

Hi,

I'm feeling really stupid right now, the bug was in my code.

Sorry.

Mate

Hi Mate,

Not to worry, I had many a puzzling day working on sub-surface scattering and point clouds The pc functions are quite powerful but take some time to get used to. I find that you need to think slightly differently…

Anyhow, good luck!

–Ian

Hi Ian,

thanks for the encouragement!

After experimenting further I started to suspect that the reason of my failures lies in the way how I use VEX and not the way how I use point clouds.

I took it granted that the points in a VEX sop are processed in point number order. Now I started to believe that this is not the case.

Am I right?

thanks
Mate

Hi Mate,

You're correct that you shouldn't assume anything about the order in which points are shaded. It may very well be the case that they *are* shaded in order, but we make no guarantees about this and so this could change. In addition, if you are shading with multiple threads, you will almost certainly run into problems if you assume a certain ordering. Hope that helps. Cheers!

Hi Ian,

thanks for the affirmation. This bad assumption was at the root of my problems, and it was a bit hard to track down, since just as you said ‘sometimes’ VEX do things in order.

One have to always keep in mind, that VEX is a shading language, and not a general one. Thanks again for the illuminating conversation!

regards
Mate