Hi,

Houdini's Packed Primitives, are these similar to .ass files or .emdl's?

Reading the info on this, it sounds like a similar workflow for distributing/rendering vast amounts of (external) geometry.

cheers,

rob

I am not sure, but I think they work as some kind of accelareted instance geometry.

RobW
Hi,
Houdini's Packed Primitives, are these similar to .ass files or .emdl's?
Reading the info on this, it sounds like a similar workflow for distributing/rendering vast amounts of (external) geometry.
cheers,
rob

They are generalized instanceable/shared geometry container (i.e. primitive) that is one level bellow concepts like .rib/.ifd/.mi/.emdl/.ass (in that order btw).

They can hold arbitrary complex geometry which is to be treated as a single primitive allowing for numerous optimizations like layered instancing and efficient handing in viewport/mantra.

Loosely speaking they are similar to a concept of pointer to void data in c++ programming. And yes they can be written down to both bgeo and ifd files which means they can be referenced similarly to .ass.

Thanks,

just trying to get my head around the new terminology and tech

It is also good to think of Packed Primitives saved inside a .bgeo file as similar to .abc Alembic files on disk.

What is confusing is that the .bgeo format supports all Houdini primitives, including packed primitives, packed fragment primitives and Alembic primitives.

So…

A .bgeo file that only contains Packed Primitives can be treated similarly to an .abc Alembic file. Both are delay load type primitives to Mantra. Only a single point with attributes (bounding box for instance) is put in to the ifd file and when Mantra hits the bounding box,it will then load in the primitive from disk (or memory in the case of Packed Primitives in memory). There can be one or more deferred type primitives in a .bgeo and .abc file. Typically there are a lot of delay load primitives in the .abc or .bgeo file.

Phew…

Hi jeff!
Can we expect that packed primitives will continue to evolve in houdini, so that current workflow with procedurals (fast point/delayed load) will be replaced with copy-stamping + packed primitives?

Packed primitives are awesome, but pretty useless when stamping comes to play…..

jeff
It is also good to think of Packed Primitives saved inside a .bgeo file as similar to .abc Alembic files on disk.

What is confusing is that the .bgeo format supports all Houdini primitives, including packed primitives, packed fragment primitives and Alembic primitives.

So…

A .bgeo file that only contains Packed Primitives can be treated similarly to an .abc Alembic file. Both are delay load type primitives to Mantra. Only a single point with attributes (bounding box for instance) is put in to the ifd file and when Mantra hits the bounding box,it will then load in the primitive from disk (or memory in the case of Packed Primitives in memory). There can be one or more deferred type primitives in a .bgeo and .abc file. Typically there are a lot of delay load primitives in the .abc or .bgeo file.

Phew…

:roll:

Yes there will be continual improvements to support lighting and rendering as we use the Packed type primitives more and more in clever ways. Nested instancing with packed packed primitives is still not full-on for rendering but certainly is a powerful strategy for scene assembly. I am packing up hierarchies to copy stuff about and then prior to rendering, unpack to the root packed prime and then render. In essence distilling the packed hierarchies to what Alembic has (as alembic currently doesn't support packed packed hierarchies, only flat object packed hierarchies).

As for instancing and per-instance variation, that is possible right now but requires a bit of a workflow tweak for H13.

You can use the Renderstate VOP to fetch per packed prim id's and do random variation within the shader. Not ideal but it is possible and yes shows that there is work to be done to streamline all of this.

See the attached scene file with comments on how to do this right now. We know that customizing the shader with Renderstate VOPs to tell Mantra what attributes to keep as it unpacked the primitives is not ideal but it does work.

But seeing the actual instances as deferred rendered primitives is highly addictive. You can run some massive sized environments.

Hey Jeff,

When it comes to stamping geometry which have stamp expressions that change the stamped geometry, you can obviously make PackedPrims of them while stamping, but they'll all be unique, thereby not re-using any models, even if the stamp-based modeling operation resulted in identical geometry.

So I had an idea to prototype a “Pack Optimize SOP” which scans through all (memory) packed prims and generates a hash for each, and replaces identical geometry with a copy of one of the packed prims – essentially unique'ing the geometry. For my prototype I ran into a limitation that there is no hou.PackedPrim.unpack() function, and so it'd have to be HDK – which I can't get to work on my Windows machine.

I was doing a poor-man's hash just checking P, using hashlib:

node = hou.pwd()
geo = node.geometry()
import hashlib
md5attr = geo.addAttrib(hou.attribType.Global, “md5”, “”)
hash = hashlib.md5(geo.pointFloatAttribValuesAsString(“P”)).digest()
geo.setGlobalAttribValue(“md5”, hash)


… where in the HDK I think I might be able to unpack and use UT_Hash_Ptr against the entire gdp (but I may be wrong there; I should test this sometime) rather than just against attributes/etc as it needs to be robust against topology changes too.

In any case, I think this might be useful; and also this could be done efficiently on the fly in the Copy SOP if the Copy SOP is doing the packing, maybe?

..

But back on topic, we are all hoping for more opportunities to execute some operations within Mantra, as a final stage adjustment right before rendering begins. This might let us re-use packs until the very last instant, and then make them unique (when, obviously, Mantra has to expand pack instances into copies).

Of course Jeff is right that you can shade and displace them uniquely already, using the renderstate(“packed:someattribute”) VEX operation.

jason_iversen
Hey Jeff,

When it comes to stamping geometry which have stamp expressions that change the stamped geometry, you can obviously make PackedPrims of them while stamping, but they'll all be unique, thereby not re-using any models, even if the stamp-based modeling operation resulted in identical geometry.

So I had an idea to prototype a “Pack Optimize SOP” which scans through all (memory) packed prims and generates a hash for each, and replaces identical geometry with a copy of one of the packed prims – essentially unique'ing the geometry. For my prototype I ran into a limitation that there is no hou.PackedPrim.unpack() function, and so it'd have to be HDK – which I can't get to work on my Windows machine.

Hey Jason,

There's an option in the copy SOP “Cache Stamping Geometry”. What this does is permute through all the possible stamping parameters and cache geometry for each unique permutation. So, for example:

Say you have a switch SOP with 5 different input shapes that you're stamping 1000 times.

Without the “Cache Stamping Geometry”, you'd end up with 1000 packed primitives, but also 1000 pieces of unique geometry.

With the “Cache Stamping Geometry”, you'd end up with 1000 packed primitives, but they would share the 5 unique geometries.

Oh, this option also works if you aren't packing geometry. Which is why the option is off by default. In the non-packing case, you would end up with potentially twice the geometry in memory at once.

But I like the idea of the “optimize packing” SOP.

I'm not sure exactly how / if this can apply, but for 3dsmax, one of the particle extensions had an operator: Discretizator: Makes float or integer values more discrete, reducing a wide range of values to a more manageable subset by rounding up or down. This can provide a marked improvement in the speed of handling large particle systems.

It's generally used when modifying geometry for instancing onto the particles. IE: Mountain sop random offset for each point. My thought was that there could be a ‘rand’ function in Houdini that did the same thing (maybe there is), so when doing a copy/stamp setups, you would end up maybe creating 100 unique geometries just by discretizing the rand value, instead of creating 1000 unique geometries.

P.S. Typically the switch sop is the better option, I was just thinking that this as an overall idea is cool.

Solitude
…Discretizator: Makes float or integer values more discrete, reducing a wide range of values to a more manageable subset by rounding up or down….

Could this be done with stamping expression?

Something like this:
fit(round(fit01(rand($PT),0,ch(“nd”))),0,ch(“nd”),0.0,ch(“maxval”))

Where:
nd = number of discreet steps
maxval = top value of the range expression

(e.g. if I want uniformly distributed 5 random numbers between zero and 20 then nd=5, maxval=20)

I also added scene example.