My shader needs dense point clouds for small search radius, but at the same time I need it to do large search radius, the objective being to perform small and large blurs then average them together.
The problem is that large radius's unnecessarily catch a whole lot of points (like a couple thousand or more, whereas I only need 100 tops) and of course that takes ages to render.
So my question is… Is there a way to force the filtering part of a pc shader to skip say 9 points in every 10?

The point cloud shader is the simplest possible in vops, it just reads baked lighting (baked with pcwrite).

cheers

S

You should be able to specify the number of points when you call pcopen() in the shader. Or am I misunderstanding?

Andrew

The problem is that reducing the number of points until it is less than the number that actually exist within the search radius will reduce the size of the blur. I guess this is because the searching sorts the points based on distance, rather than a random or skipping manner.

Its a RFE I guess

hope this makes sense

s

Serg
The problem is that reducing the number of points until it is less than the number that actually exist within the search radius will reduce the size of the blur. I guess this is because the searching sorts the points based on distance, rather than a random or skipping manner.

Its a RFE I guess

hope this makes sense

s

Yes it makes sense, and it's something that pyro (and a bunch of other applications could use). You want to access the point cloud as a “brick map” or an octree, where a lowres search would return the average attribute value of all points within a “brick” (at a certain subdiv level).

Yeah I though it might be useful for Pyro too.

As you probably guessed my application is a simple `nvidia human head` like sss shader… I have to pcwrite at a decent shading quality for the detail but this of course means that when the shader is doing the big blurs it will have to fetch about 10000 points in close up shots.
I could do several pcwrites at different resolutions (and thus equal number of Rops and takes) and switch between them based on blur radius… but that is highly impractical

I was hoping it might be just a matter of finding the farthest and nearest point within the search radius then sort npoints between them. But I understand it may not be that simple.

cheers
S

I do not quite get this all pc mess.
From what I've read and thougth pointclouds are fully loaded into memory because they are not partitioned…(a few sentences about TBF here ).
That makes them pretty useless in big scenes.
That's why they use octrees in prman and some other. Octree is a mipmapped structure for efficiently wrangle pointclouds, and prman has it for a couple of years now.

Also…this octree is easy to implement and there are some ready and free pieces of c++ code on the net.

So…if houdini has quite mature pointcloud functions now, where is this octree thing 8) ?

It's funny, pointclouds are used to make rendering faster and more memory efficient, and now in houdini they are not as useful because of this tiny little lack of tree :shock:

This subject comes from time to time without any solution.
Can you put some raytraced area light on it

peliosis
Octree is a mipmapped structure for efficiently wrangle pointclouds, and prman has it for a couple of years now.

You are confusing filtering and partitioning. Octrees/grids/kd-trees, etc are only a method for spatial subdivision to accelerate data lookup (or reduce memory when looking up data from a file). Such a data-structure may be extended to contain for each node some information about it's child nodes (average values, sum, etc) - such a structure is “filtered”, e.g. renderman's brickmap.

For example: 3Delights/PRman point couds are tiled (don't know if they use a grid or octree exactly), but they are not filtered - each node contains just the points. Brickmaps are pre-filtered - once the octree is created, starting from the leafs an average of their values is computed, all the way up to the top (root) node - just like a texture mipmap.

Thanks for clearing it Diula.
The longer I dig the subjects the more questions arise.
How are pointclouds different from normal gi/fg cache in MR or Vray or mantra irradiance cache.?

I know they can have more purposes but what about data acceleration structures in all of them?

I understand pointclouds are so efficient in use with scanline rendering, but houdini pointcloud shader for ao/gi uses raytracing on points, how is it different from MR/Vray caching?

It's not adaptive so we get more points where they are not needed. It's not prefiltered so we loose memory efficiency = using photon/irradiance/whatever atlas is impossible now.

Still…if we have an atlas(whole scene pointcloud or brickmap as in pixar paper) how does it differ from eg. MR fg/gi cache generated for whole scene, apart from rendering technique difference?

Are these all cache points using different acceleration structures and access way?

3delight pc's are not load into memory.

I'm puzzled and tired, don't get it too serious

Some icing yet:

Does new prman server use the ao/color bleeding technique pixar writes about in a paper with palmtrees (http://graphics.pixar.com/library/ [graphics.pixar.com])?


EDIT: ok, I'd better get lost <VeRy hApPY>