i3d, brickmaps, and pointclouds, oh my

[mrice]

I've tried to do my due diligence, but haven't come up with any concrete answers.

Can anyone confirm or deny these suspicions?

1. There's no direct interface in houdini/mantra from pointcloud to i3d, as there is from pointcloud to brickmap in prman. It can be done, but the process would be highly inefficient

2. Unlike prman, mantra *does* have the ability to do tiled lookups in a pointcloud from disk, determined by the "preload" argument to pcopen()

3. Assuming number 2, what we're missing from prman's brickmap is the ability to do a lookup to a specific tree level. This could be faked reasonably well though, and the performance difference might be negligible.

I'd really appreciate any insight. Thanks!

[pclaes]

Good questions!

I have been looking into this as well and as far as my current understanding goes there is no ordered pointcloud file format to store your points into from within houdini.

Which implies that even with pcopen the pointcloud will need to be fully loaded, then the kd-tree is internally built and from that you can start to do the quick lookups.

I also picked up that brick maps are very similar to rat textures. In the sense that they store the different tree levels in a single file and have the ability to only load the required level in memory.

In the HDK there is the pointtree class that allows you to build a tree. So the code and algorithms seem to be all there, what is missing is the ordered pointcloud file format. It would be great if this could be added as a supported file format similar to brickmaps.

[lisux]

Good questions!

I have been looking into this as well and as far as my current understanding goes there is no ordered pointcloud file format to store your points into from within houdini.

Which implies that even with pcopen the pointcloud will need to be fully loaded, then the kd-tree is internally built and from that you can start to do the quick lookups.

I also picked up that brick maps are very similar to rat textures. In the sense that they store the different tree levels in a single file and have the ability to only load the required level in memory.

In the HDK there is the pointtree class that allows you to build a tree. So the code and algorithms seem to be all there, what is missing is the ordered pointcloud file format. It would be great if this could be added as a supported file format similar to brickmaps.

Yep this remember to me and old RFE, a lookup, or spatial mode in the geo format. This way we can have lots of points/particles in a bgeo and have a fast and optimized way to access this data.

This will be really good and a diference with other apps.

And for the brickmaps and rat format, well I think they are more similar to i3d format, with stores information in 3 dimensions as brickmap and also support tilled(voxels) lookups like rat files.

This is what I remember now from i3d, so I hope not be making a mistake here.

[Jason]

Houdini's .i3d and .pc files are spatially organized/tileable -- and there has been talk of developing a geometry format having this nature too. I can see this being a bit of a challenge, especially if you're needing to maintain prim order and such. (Glad I'm not writing it;))

But yes, mrice, it would be nice to be able to load finer and coarser levels of the kd-tree:)

PS. V-Ray uses an intermediate geometry format which is spatially organized -- and apparently gives them some memory and, in some cases, speed boosts.

[mrice]

Thanks for the replies so far

Houdini's .i3d and .pc files are spatially organized/tileable

Hmm that's what I was assuming in number 2 above, but I just did some (not so) quick tests with large pointclouds, and I don't see any improvement from not preloading the pc. There's an environment variable that controls the buffer size I didn't factor in, but in any case it doesn't look like we can get some kind of fast lookup directly from .pc files. Mantra is doing some long (singlethreaded, probably by necessity) preprocess even when "preload" is off.

I'll do some tests with i3d/texture3d, but I don't think that's going to be viable for me anyways because getting from pointcloud to i3d won't be a fast process.

[brianburke]

PS. V-Ray uses an intermediate geometry format which is spatially organized -- and apparently gives them some memory and, in some cases, speed boosts.

What's different between a spatially organized geometry format and binary space partitioning (like Mantra does)? As I understand it, they are the same thing.

thanks

Edited March 2, 2010 by brianburke

[lisux]

What's different between a spatially organized geometry format and binary space partitioning (like Mantra does)? As I understand it, they are the same thing.

thanks

Just on top of my head, Vray can save this king of partition distribution in a file, whereas Mantra do all the stuff in RAM,there arent any file format thta can store geometry data in such way.

[brianburke]

Just on top of my head, Vray can save this king of partition distribution in a file, whereas Mantra do all the stuff in RAM,there arent any file format thta can store geometry data in such way.

Cool, thanks for the clarification.

[Jason]

I believe the cache used by Mantra is the "vm_texcachesize" -- which also controls other cache sizes. Underneath it all, i3d, rat and pc all utilize their TBF structure. (default 32mb)

Thanks for the replies so far

Hmm that's what I was assuming in number 2 above, but I just did some (not so) quick tests with large pointclouds, and I don't see any improvement from not preloading the pc. There's an environment variable that controls the buffer size I didn't factor in, but in any case it doesn't look like we can get some kind of fast lookup directly from .pc files. Mantra is doing some long (singlethreaded, probably by necessity) preprocess even when "preload" is off.

I'll do some tests with i3d/texture3d, but I don't think that's going to be viable for me anyways because getting from pointcloud to i3d won't be a fast process.