takita

jpparkeramnh
Jeff Wagner talks about pgfind in his VEX masterclass and touches on point clouds a little bit, but sometimes it's hard to creatively imagine novel uses for these.

Hi Jon -

This may or may not be helpful but in the vellum solver (for the grains) there's a VOP called “get_neighbors” that uses both pcfind and pcfind_radius (switched by the “uniform_radius” parameter), and there's a bit commented out on pgfind (which IIRC is for accessing points that are spatially partitioned in to blocks the way a VDB might, could be wrong tho) - all of that could be a bit of a clue as to what the finer distinctions between them are.

-T

sanostol
it is not a ideal solution, but maybe this helps a bit. a inline node packed as an otl, it renames the parameter to fit the code and exports it to the vopnode

You can also set it inside the vopnetwork to the desired path

Nice, thanks for sharing!

-T

Julian Johnson
The best example I can give of this is the problem of feeding the global transform of a driver object into a VOP SOP in my roll object scene. In ICE this is simply a question of dragging the Global Transform into the simulated ICE tree. Each frame I can store the old transform and then compare it to the new. Very simple. In Houdini, however, it seems more complex - possibly because I haven't found the best way yet. Certainly there are a lot more choices involved.

Hi Julian -
I agree with you completely that data access in VOPs could be improved, especially WRT getting object transforms in to the graph.

One (slightly inelegant) way is to use the optransform() vex function and an inline code VOP to grab the full transform matrix. It's nice because you get the full matrix in one shot but it can also be inconvenient in that the inline code VOP disallows duplicate variables anywhere within the same VOP sop, so if you have multiple transform sources you will need to go and edit each of them manually (instead of just changing a single “SOP path” parameter or something).

cheers,

-T