In the attached hip file I have a simple python sop that takes a reference to pwd().geometry().freeze() and then clears the contents.

According to the documentation for freeze() this should not affect the sop output as the ‘live’ geometry is not being affected - only the frozen geometry. However, this code clears the live geometry as well.

What's going on here? Am I using the freeze() method incorrectly, or is this a bug?

Regards,

Andrew

Ah – clearing the geometry from a Python SOP will clear the cooked geometry, regardless of whether or not it's frozen. I've updated the documentation to hopefully better explain how frozen geometry works:

freeze(self) -> hou.Geometry:
Return another Geometry object that is not linked to a particular SOP.

Normally, when you call , the resultant Geometry
object retains a reference to that SOP, and is said to be unfrozen. Each
time you access points, primitives, attributes, etc. in an unfrozen
Geometry object, Houdini uses the SOP's latest cooked geometry. So, if you
change parameters or change the time for an animated SOP, the Geometry
object will update to the SOP's new geometry.

Unless Python SOPs are involved, a frozen Geometry object does not have a
similar live association with a particular SOP. If you ask a SOP for its
geometry and then store a frozen copy of that geometry, when the SOP
recooks the frozen Geometry object will not update. Instead, the frozen
geometry saves its own copy of the point and primitive data, and is
unaffected by subsequent changes to the SOP. When a frozen Geometry object
is destroyed, any geometry copy it created is also destroyed.

Note that accessing a Geometry object's points, primitives, attributes,
etc. may be faster when dealing with frozen objects. You may want to work
with frozen Geometry in speed-sensitive operations.

Calling this method on an unfrozen Geometry object returns a frozen
one. Calling it on a frozen object has no effect, and it returns
a frozen object.

When a Python-defined SOP cooks and runs Python code that asks for the
SOP's geometry, the returned Geometry object is writable. Modifying this
Geometry object affects the output of this SOP. For efficiency, this
geometry object is already frozen, so calling freeze on it has no effect.

Thanks, Lucas.

Hi Lucas,

I'm having a bit of a memory leak problem with a Python/inlinecpp SOP which might be related to that last bit of information you provided about automatically created frozen geometry (I'm glad I looked here first).

My phython SOP code is roughly this:

geo = hou.pwd().geometry()
partfile = hou.evalParm(“partfile”)
loadmodule.LoadPartFile(geo, partfile)

where LoadPartFile is an inlinecpp code that loads binary data and generates points (tons of it). This code starts accumulating memory when I do a flip book and never frees it. However if I change the code to:

partfile = hou.evalParm(“partfile”)
loadmodule.LoadPartFile(hou.pwd().geometry(), partfile)

Everything is fine. Note that this one leaks as well even though I don't use geo at all:

geo = hou.pwd().geometry()
partfile = hou.evalParm(“partfile”)
loadmodule.LoadPartFile(hou.pwd().geometry(), partfile)

Could this be related to automatically freezing and not properly freeing this frozen geometry?

Thanks,

–Tolga

I'm reviving this old thread, since its the only place I've seen talk about the python hou geometry freeze function.

I'm trying to wrap my head around this, but it doesn't make sense to me-

with freeze, is it possible to stash geometry within a hip file and ensure it wont be destroyed even if the input is disconnected?

It sounds like it could be similar to locking a node, but I've tried to achieve this behaviour without any luck. Are there any examples that can show its usage? I'm not sure if I'm on the wrong track here for what this function could be used for.

I'm hoping to be able to store some point data within an otl for moddeling. I'm trying to avoid writing the data out to disk. using a locked node would be nice, except it can't be done inside a locked otl. I don't want to lock the otl though, because that seems to break versioned updates to the otl.

Thanks if anyone has pointers.

queglay
It sounds like it could be similar to locking a node, but I've tried to achieve this behaviour without any luck. Are there any examples that can show its usage? I'm not sure if I'm on the wrong track here for what this function could be used for.

Hey!

Locking an HDA/OTL simply makes it so you can't edit what's inside. Freezing a node with the snow-flake icon saves the geometry data at that node. From my tests, it seems like within an HDA, one can freeze nodes, and this frozen geometry is saved with the HDA.