Pack primitive and trasform

   2472   9   2
User Avatar
Member
26 posts
Joined: Aug. 2014
Offline
Hi, I have quetion about Pack primitive and trasform

I imported alembic file with lots of primitives and when I try move by "transform" one primitive it works quite fast and responsive. It is exactly what I expect because I am moving one point.



But...

After I unpack and pack again the situation has changed dramatically

Technical it is still one point so it should be fast the same like on beginning - yes?

Name atrybute: path
Create packed fragments: off


Attachments:
startPP.gif (7.5 MB)
endPP.gif (6.0 MB)

User Avatar
Member
26 posts
Joined: Aug. 2014
Offline
All I have left is to wait for the new version Houdini.. 19
User Avatar
Member
68 posts
Joined: Sept. 2018
Offline
I think when you modify the xform node Houdini have to cook the chain again everytime you do it.
It seems that the node information contains the process time.
Edited by goose7 - Jan. 29, 2021 07:57:31
User Avatar
Member
603 posts
Joined: July 2013
Offline
The Geometry Spreadsheet is your friend here....also the Node Information window would've answered this as well..

Packed Geo is compressed in memory and that's why you have a faster DCC viewport, because, its is indeed only transforming a single point.

Unpacking the Geo removes that compression and the DCC viewport bears the full weight of the Geo, all the points, vertices, primitives, etc.,......hence, a slower DCC viewport.

I would imagine that building in your example, belongs to Group 46, so whether or not you are Packed/UnPacked, you can still isolate that building using that Group identifier - which makes it "appear" to you as if you are still interacting with a single point when UnPacked, when in fact, you are interacting with the full geo of your Alembic file, but, isolating data that belongs to Group 46 only for your Transform operation.
Edited by TwinSnakes007 - Jan. 29, 2021 10:26:14
Houdini Indie
Karma/Redshift 3D
User Avatar
Member
26 posts
Joined: Aug. 2014
Offline
it makes sense for me.
But, it should be some "compressed Node" to compress again - yes?

Because (for user) it is only like you say "single point"
User Avatar
Member
8506 posts
Joined: July 2007
Offline
I'd assume they'd have the same performance, as long as they are not Packed Fragments (but you said that's unchecked)
it's possible though, that there is some more optimization on packed alembic viewport support
Edited by tamte - Jan. 29, 2021 13:25:32
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Member
26 posts
Joined: Aug. 2014
Offline
tamte
it's possible though, that there is some more optimization on packed alembic viewport support

It may be so.

SideFx should do something about it
User Avatar
Member
603 posts
Joined: July 2013
Offline
tamte
I'd assume they'd have the same performance...

My understanding is a Transform is a Matrix operation per-point.

So, if my model, for example, has 100million points, I wouldnt expect that operation to be the same time for 1point vs 100million points.
Edited by TwinSnakes007 - Jan. 30, 2021 09:11:21

Attachments:
PackVsUpack.jpg (155.2 KB)

Houdini Indie
Karma/Redshift 3D
User Avatar
Member
8506 posts
Joined: July 2007
Offline
We are talking about Packed Alembic primitive VS repacked as Packed Geometry primitive as per first post
So in my head it comes down to how efficiently viewport can handle updating such geo behind the scenes
Cause for transform it's just updating one matrix in either case
Tomas Slancik
FX Supervisor
Method Studios, NY
User Avatar
Member
603 posts
Joined: July 2013
Offline
..ahhh, I knew it was something I was missing, well, then, that would depend on HOW it was being re-packed - since Pack SOP is user configurable, you control the granularity.

Assuming that the Pack SOP was configured correctly, then yes, they should behave the exact same.
Houdini Indie
Karma/Redshift 3D
  • Quick Links