Hello,

I am having trouble understanding some of the concepts included under the topic of point clouds. It seems very esoteric to me. This is what I currently understand (or think I understand):-

Pcopen
Pcopen opens a point cloud file for searching through and returns points based on search parameters like radius (distance from the query position), and only returns up to a maximum number of points (specified by the user).

This node I think I understand. My only questions are ones of terminology.

1. Why is the point cloud to search through called the 'point cloud texture'?

2. Why are the various bits of data you lookup in the ‘point cloud texture’ called ‘channels’? Why are they not called attributes? When the pcopen vop asks for what the bit of data is called in the point cloud texture that stores each points position, why is it labelled and refered to as the ‘position channel’? Suddenly with point clouds attributes become channels?

3. Why are the returned points called the 'point cloud handle'?

I guess these questions aren't too important, but personally I find the unfamiliar terminology is one of the factors in impeding (at least my) understanding of the subject. If I knew why these terms are used, hopefully it will help cement my understanding.

Pc filter
Another one I think I am fairly clear on. Pc filter takes the point cloud ‘handle’ returned by pcopen, and looks at the data on them (data/attributes/channels) and returns an averaged result based on the weighting formula given on the help card.

My questions for this node:-

1. What ‘channels’ can be queried? In the attached hipfile, pc filter successfully queries P and successfully queries the created attribute, ‘pointnum’. As I am only returning 1 point from the pcopen search, no weighting or averaging takes place so I get back P or pointnum with the same value from the closest single point returned. That's fine. Why doesn't it return anything for the other attribute, ‘myrand’? Does pcfilter only return channels/attributes of specific names like P and pointnum? If that's the case, are these the only 2, are there more? Are they documented?


Pc Iterate
I think this one is fairly simple. Starts the iteration over or moves on to the next point in the iteration, of the point cloud handle of found points from pcopen. Plug this into a while vop which is basically saying ‘while there is another point to iterate over, do the stuff inside the while vop’.


Pc Import
Only use inside the pc iterate loop. Takes the current iteration point and pulls in data from its attributes/channels. Questions for this node:-

1. The helpcard says you can import 2 special channels, point.number and point.distance. Are these the only 2 channels/attributes you can import? If so how do you import other channels/attributes/data from points returned by a pcopen search if seemingly pc Filter doesn't do it either (in the above example of ‘myrand’)? I guess store the result of point.number and then use that after with an import attribute vop?


pcunshaded/pc export
Now this one I'm totally in the dark about. The helpcard states that this is somehow different to pc iterate in that it ‘only iterates over each point once’.

1. How is this different? It was my understanding that pc iterate iterated over all points one by one, hence once per point?

2. Again I am confused by the terminology. The helpcard says you should then use pc export to store ‘shaded information’. What does it mean by ‘shaded’ and ‘unshaded’? I have absolutely no idea!

3. The pcunshaded vop has a ‘unshaded channel’ parameter. What sort of attributes/channels should be plugged in? The help card for the vex function says its for channels that have not been written to. Does this mean its for empty attributes? If so how do you create an empty attribute? They usually have default values.

Generally speaking, I guess I have no idea what pcunshaded is for.

General Questions

1. The help says that generally you should use pc close to close the point cloud you've been iterating over. Where should this go? I was playing around with where to put it, but it either seemed to stop the loop working as it no longer outputted data or didn't get rid of the warning. As with the other point cloud nodes, there doesn't seem to be any examples of how to wire these nodes together in the help card, or to show how they should be used/how they are useful.

2. In the attached hip file (I can't remember where I got the hip from, I must have d/loaded it from here or OdForce at some point), pc closed has not been used, but instead inside the while vop there is a switch and an extra pc iterate which seems to satisfy the need to close the point cloud, but I have no idea how/why? The switch index is not wired to anything.


I know this is a long post with a lot of questions, so I'd like to say thanks in advance to anyone who can finally shed light on this for me, for years its been something I have used but never really understood, and skirted around.

alexcb
1. Why is the point cloud to search through called the 'point cloud texture'?

Because in a wider context this is what point clouds were designed for. As you probably know, a common procedure in computer graphics is to access images stored previously in a files and use them as a textures to drive different properties of a surface or other parameters of objecs.

Images, as they are stored inside computers, are very decent type of data, because they are well parameterized. That is, images have just a few dimensions (two, sometimes three), which can be discretized (divided) into equal chunks (pixels/voxels) and placed linearly, that is one after another, into computer's memory. In other words, they map pretty well to memory model of computers, what makes them efficient companion for most image algorithms. This may sound trivial, but it's actually a rare case in a world of data structures. Thanks to these properties, accessing even huge amount of pixels (even bigger than computers' memory), is possible and quite efficient. Thus they are used in CG a lot.

Quite often you don't have that luxury of well organized data like images though. Point clouds which are very common in 3d are such case. If you want to use them efficiently, you need to pre-process them and build a data structure suitable for further fast accessing and processing. This is what point clouds term in VEX is all about.

Most of the time, not only in VEX, but in other applications as well, this data structure is called KD-Tree [en.wikipedia.org] ( or Oct-trees in case of pointcloudlod() VEX call), and actually most of your questions refer to technicalities of working with kd-trees in Houdini. Secondly your questions come from the fact, that Houdini documentation regaring VEX, not always distinguishes clearly bewteen two domains for point clouds: Houdini and Mantra.

So short answer to your questions: point clouds are often referred as textures per analogy, since they are in fact a data structures created to be used similarly to raster textures – images, but on different data types like point clouds or any scattered measurements of 3d domain.

2. Why are the various bits of data you lookup in the ‘point cloud texture’ called ‘channels’? Why are they not called attributes? When the pcopen vop asks for what the bit of data is called in the point cloud texture that stores each points position, why is it labelled and refered to as the ‘position channel’? Suddenly with point clouds attributes become channels?

This comes from a previously mentioned analogy I would say. Channels are attributes of a textures. Also, you should know that the origin of point clouds in Houdini is rendering context, in which channels/textures are first class citizens. In SOPs land these may sound little less obvious.

3. Why are the returned points called the 'point cloud handle'?

Handle is just an integer saying Houdini, which point clouds among many possibly created previously you are referring to. Not sure how much you know about programming, but VEX is not (was not?) object oriented language back then, and such idiom is popular workaround for working with persistent objects in memory in languages without a notions of an objects. Specially in cases, when multiply threads are going to access single object they don't own, you provide a handler to the object which is private otherwise. To put is short: the whole point of creating point clouds is to amortize cost of searching through your data set. KD-Tree is temporary data structure, which is costly on creating, but super fast at access and can be reused endlessly as long as an underlying data is constant. When you use Point Clouds Open VOP, you create a point cloud texture object in memory, and then all functions refer to that object via handler.

Pc filter

1. What ‘channels’ can be queried? In the attached hipfile, pc filter successfully queries P and successfully queries the created attribute, ‘pointnum’. As I am only returning 1 point from the pcopen search, no weighting or averaging takes place so I get back P or pointnum with the same value from the closest single point returned. That's fine. Why doesn't it return anything for the other attribute, ‘myrand’? Does pcfilter only return channels/attributes of specific names like P and pointnum? If that's the case, are these the only 2, are there more? Are they documented?

Nope. Any attribute of the points you created your points cloud from, can be queried. I'm not sure why your scene doesn't work, but it seems it behave correct once you specify a file in pcopen with Opinput2, not the expression you use.

One thing about points clouds is that they are not always deterministic. They were designed to allow multi-threaded, very fast access and interpolation of heavy data sets, but to be fully predictible so for example order of points returned by pciterate may vary from execution to execution.

pcunshaded/pc export
Now this one I'm totally in the dark about. The helpcard states that this is somehow different to pc iterate in that it ‘only iterates over each point once’.

1. How is this different? It was my understanding that pc iterate iterated over all points one by one, hence once per point?

pcunshaded is solely for rendering context, in which mantra creates points for a shading purposes. Unlike pciterate, inside pcunshaded you most probably will write data to points cloud, not read from it. Most often this data are shading output, like color of a surface, light energy (photons in Mantra are implemented with points cloud infrastructure).

I'm not sure, but it's quite probably that Mantra doesn't know how many points it will iterate over when it enters pcunshaded loop.

2. Again I am confused by the terminology. The helpcard says you should then use pc export to store ‘shaded information’. What does it mean by ‘shaded’ and ‘unshaded’? I have absolutely no idea!

See above, this applies to Mantra shaders, not SOPs.

It seems some part of Point clouds docs are outdated though.

If you are using it as a point lookup, go straight to Point Cloud Find or Point Cloud Find Radius and ignore the other Point Cloud functions.

To answer your curiosity, point clouds originally were .pc files, a special type of .tbf file that is an image file format. Thus the strange image-based notations. Support for .bgeo came later, and eventually became the dominant approach.

The ugliness of point cloud close is because the looping semantics were built before we had VOPs so were meant to be written in pure VEX. It is rather treacherous to get the right code generation in VOPs for a pciterate loop, which is why I'd strongly recommend pcfind.

jlait
If you are using it as a point lookup, go straight to Point Cloud Find or Point Cloud Find Radius and ignore the other Point Cloud functions.

To answer your curiosity, point clouds originally were .pc files, a special type of .tbf file that is an image file format. Thus the strange image-based notations. Support for .bgeo came later, and eventually became the dominant approach.

The ugliness of point cloud close is because the looping semantics were built before we had VOPs so were meant to be written in pure VEX. It is rather treacherous to get the right code generation in VOPs for a pciterate loop, which is why I'd strongly recommend pcfind.

It would be nice if the docs compared pcfind, pgfind and pcopen. When to use pgfind for instance. I use pcfind nowadays but when I need to use pcfilter for any type of attribute, I revert back to pcopen because there is no equivalent in pcfind. I submitted an RFE about it a year ago .

I think pcfind functions were added to support the new Grains Solver but were left untouched afterwards instead of making it equivalent to old pc functions in every use case.

Thanks for your explanations SYmek and Jeff, it's really good to be able to link these unfamiliar terms (at least in this context) to the legacy as to why they are used. It helps me link things together in my mind!

Nope. Any attribute of the points you created your points cloud from, can be queried. I'm not sure why your scene doesn't work, but it seems it behave correct once you specify a file in pcopen with Opinput2, not the expression you use.

Hmm, this functionality would be very useful then if I could get it to work!! So you're saying instead of pointing the second input to an operator I should point it to a .pc/.bgeo file on disk and it will work?


I'll check out the pcfind vop also! Thanks again.

Hello, just a small notice, as regards the attached file and your question “Why doesn't it return anything for the other attribute, ‘myrand’?”


It is because you reference this SOP “opobj/pc_open_stuff/attribcreate__ptnum” but you specify the “myrand” attribute later in another SOP downstream.