I am rendering a crowd of characters using fast point instancing to load bgeo files from disk.
Using the instancefile attribute, I am loading a different character and frame of animation per point.

Initially I had a large point cloud that filled the frame and Mantra would pre-load all the geometry needed for that render. In some cases this was hundreds of individual bgeo files.

ptinstance creating proc with ‘…../clipEfull/GEO_clipEfull_v0002.0077.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipDfull/GEO_clipDfull_v0002.0090.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipDfull/GEO_clipDfull_v0002.0053.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipEfull/GEO_clipEfull_v0002.0146.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipEfull/GEO_clipEfull_v0002.0006.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipBfull/GEO_clipBfull_v0002.0157.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipFfull/GEO_clipFfull_v0002.0069.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipDfull/GEO_clipDfull_v0002.0058.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipBfull/GEO_clipBfull_v0002.0057.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipEfull/GEO_clipEfull_v0002.0116.bgeo’ -> ‘(null)’
ptinstance creating proc with ‘…../clipEfull/GEO_clipEfull_v0002.0024.bgeo’ -> ‘(null)’
(etc, etc)….


I can swallow the memory requirement at present, but I am wondering if there was a way of making this behave more like a delayed load procedural, with a bounding box to determine when to load the geo / textures.

I put together a vop tool to split the points dynamically into screen-space clusters (a grid of X by Y chunks) that I broke into separate objects and rendered as smaller point instance objects. This renders fine, however all the geometry is still loaded before the render begins. Would I have to make each of these objects a DLP and load these individually? Or should the fast point shader be able to work out when the geometry needs to be loaded?

- Are there any other attributes that the fast point (or full point) instancer uses that aren't documented, that can be used to define a bounding box?
- Is the fast point instancer using the Point Instance Procedural technique internally, when building the IFD file?
- I am not using the Point Instance Procedutal on my object nodes, I am just adding instance render parameters to the object and assigning the instancefile attributes. Would I have to assign the shader if i want explicit control over the bbox?

Cheers
JD

Hi,
The best performance I have got so far is using ifd archive plus instance . There's no way in Houdini to use 2 geometry procedural nodes together. See attached for a sample file with 2 examples , 1 of which uses ifs archive. If you do a search on this site there's a massive thread on point instancing I started.

Rob

Cheers Rob for taking a look.
I am back on to investigating this again. Thank you for your scene.

I have taken a look at your setup and created a bit of a hybrid with what I was working on.
I can get close to the result I want, with mantra only loading crowd geo, as and when it is needed using point instance procedurals on my clusters of points.

What I have done is (in rough ascii diagrammatic form):



||
(12 x 12)
||
(script to generate object / point instance proc, per cluster)
______________________________||______________________________
/ / / / \ \ \ \
…..
…..
\________\ _______\________\_______/________/________/________/
||



- Object Node, Grabbing the subset of the full point cloud corresponding to a particular bit of screen space.
- Point instance procedural node, assigned to a particular object.



This appears to work. Looking at the stdout, I can see Mantra loading geo as and when the buckets need it. However, this is still only happening per cluster and requires a script to generate a lot of nodes (these can be at render time). I don't know if the render-time decreases, but the memory usage appears to.
I could build a Cluster object and PIP shader, per point, but this could get a bit messy.

What would be great is a way of specifying a bounding box, per point on the original point cloud (as part of the fast-instance setup) so the IFD is build

If anyone wants me to attach the script (it has been coded specifically for this particular test), but I can patch it up into a bit of an OTL if I get time.


Rob: I saw the thread you started, and a couple of others. I am trying to collate all the knowledge together to work out the limitations of the instancer.

I currently have characters with local primitive attribs, 1 shader, multiple materials assigned to different parts of the meshes (using prim attrib switches) - lots of colour overrides per point.

At present I only have poses on individual frames, so I was thinking of caching subframes to allow for a finer degree of offsetting. (So everyone doesn't perform an action on exactly the same frame).

Next: cvex testing to see what can be achieved here.

It looks like the clusterThis tool, supports the generation of delayed load assets per point - although I havent tried this.

cheers
JD

I'll try and package up a hip / hipnc if anyone is interested

houdiniJD
Next: cvex testing to see what can be achieved here.
It looks like the clusterThis tool, supports the generation of delayed load assets per point - although I havent tried this.
I'll try and package up a hip / hipnc if anyone is interested

Yes, please post a hip file, I'm working in similar areas.

The clusterThis procedural will have some updates soon that should help (with issues outlined in this post and others).

In the past I've had huge success with CVEX processing, I hope to have some of that new code in the open source versions ASAP.


Take care,
Mark

The clusterThis procedural will have some updates soon that should help (with issues outlined in this post and others).

Excellent ! . Ive seen a few examples of cvex in action with the instancer but never pushed it more than the basics. I will keep an eye on this thread with interest.

Rob

houdiniJD
I can swallow the memory requirement at present, but I am wondering if there was a way of making this behave more like a delayed load procedural, with a bounding box to determine when to load the geo / textures.

Actually the fast point instancer uses a new feature of H12's GA library. If a bbox is written out with the bgeo file (it should by default), then it only reads the bbox from the bgeo's header, and not the geometry itself, before creating the file procedural. Only at the point where the file procedural actually gets rendered does the geometry get loaded.

houdiniJD
- Are there any other attributes that the fast point (or full point) instancer uses that aren't documented, that can be used to define a bounding box?

Unfortunately, no. A pair of attributes for explicitly setting the bbox per-point should definitely be added.

houdiniJD
- Is the fast point instancer using the Point Instance Procedural technique internally, when building the IFD file?

That's correct.

halfdan

houdiniJD
Actually the fast point instancer uses a new feature of H12's GA library. If a bbox is written out with the bgeo file (it should by default), then it only reads the bbox from the bgeo's header, and not the geometry itself, before creating the file procedural. Only at the point where the file procedural actually gets rendered does the geometry get loaded.

When using h12.0.754
Does a default bounding box get created with alembic ? I say this as I am trying to render 22k of points and using a bgeo takes 17 seconds longer than when using alembic !

Rob