Hi

My name is Kevin and my Houdini file grew to over 70Mb.

Also it keeps on growing.

I don't know what to do, please give me your best advise.

are you importing FBX files?
are you locking SOPs?

more information needed

Thanks for the reply, I really appreciate it.

I am importing a handful of fbx… hundreds, but with no bad intentions and all nodes are unlocked.

Ideally there would be a way to list all nodes and sort them by size - or is that crazy talking?

I found importing fbx, even with unlocked nodes will balloon scene size if there are animation channels. I imported one rigged character, and due to the dense keys, the file was over 200Mb on disk. I would avoid fbx if at all possible.

There is a command ‘hcpio’ that can give some insight to hip file sizes.

there is also an option on the FBX importer -> Unlock Geometry File SOPs
I've never used that option but as long as you have the original FBX and don't move it's location it should work

I find it's best to take fbx and such and bake them out to disc as packed and load them back in as native geo. Of course this isn't trivial for complex assets, but we've had all sorts of huge files and flakey renders with lots of live FBXs.

goldfarb
there is also an option on the FBX importer -> Unlock Geometry File SOPs
I've never used that option but as long as you have the original FBX and don't move it's location it should work

I've had rigs fail to recreate skinning capture data when imported this way. They work fine when imported locked.

I should have added that it's not a workflow I'd recommend.

As I have said elsewhere: FBX can be the cause of a LOT of pain in Houdini - I do recommend converting it to native geometry, too, as this will even avoid (random) crashes. Also, I can confirm that often even an unlocked FBX will increase Houdini's scene file size dramatically, whereas an unlocked “bgeo” does not. Unlocked FBX geometry does tend to not get loaded correctly when a recook is triggered.
Unfortunately, FBX is the “go-to” solution for a lot of workflows these days, because most Alembic supports are even wonkier and there is no broadly accepted alternative in sight (don't get me started on “we need a new standard to collect all the standards that exist into a new one just because we can do it”).

In short: Avoid FBX where possible, convert to not-FBX where possible.

Marc