This story about time dependency in "Sop Import", and how he generates time samples for not animated attributes.

Simple setup. Sop level. Two stream merged in one named "test":
1)Random geometry, uv, normals, packed, added unique "path" attribute (s@path = '/root/somename/')
2)Random geometry, uv, normals, packed, added unique "path" attribute (s@path = '/root/somename1/'), transform node and animated some parameters.
Lop level.
"Sop Import" imports "test".
"Load Layer For Editing" loads alembic file created from "test".

"Sop Import" - time dependent - Yes, and "push" this behavior down the stream. Sampling geometry every frame and forcing recalculation in other nodes. Playing animation as intended.
"Load Layer For Editing" - time dependent - No. Node calculates one time and just pass time sampled attribute down the stream. (I don't go deep in this, for me, it's like attribute has value not for frame, but array for all frames. But now its doesn't matter). Playing animation as intended.

This situation means that I can Import animated transform to Lop without time dependency in node.

When I export to USD "Load Layer For Editing" output, it's pretty good: two geometry, points positions, st, normals, one time sampled transformation.
When I export to USD "Sop Import" it's pretty bad: two geometry, points positions, st, normals, and for both time sampled transformation, visibility, extent. Literally for 1000 frames program generates:
And way bigger time to save file.

Questions:
1)How I can get rid of time dependency in "Sop Import", and don't use alembic? Use Cache Lop, or exists more elegant solution?
2)How you add materials to animated streams? Or more correctly, how you more efficient adding materials to animated streams?
3)How I can control which parameter get time samples, and turn of this for visibility, extent or others attributes?

Why I ask this? Q1 and Q2 simply for speed up Lop workflow, because time dependency in lop nodes its big pain. Use reference and create new USD for materials looks strange for me.
Q3 I need export animation to USDZ, and get twice larger file size, because Houdini export visibility and extent, not a good idea.
I think I miss some information, and exist more efficient way for export transformed geometry and not save this to alembic
Of course I can create two "Sop Import", for static and animated geometry. But this only help to not generate unnecessary time samples for part of entire scene, and alembic solution can separate geometry without me.

I'm not completely following your description and why you are using alembic. Re questions 1 and 3 however - on sopimport in the 'Import Data' params there's an 'Author Time Samples' option. Set that to 'If Not Specifically Excluded' and you should then be able to add the attributes you want to always be kept as defaults into the 'Set Default Values' param. Does that work?

antc
I'm not completely following your description and why you are using alembic. Re questions 1 and 3 however - on sopimport in the 'Import Data' params there's an 'Author Time Samples' option. Set that to 'If Not Specifically Excluded' and you should then be able to add the attributes you want to always be kept as defaults into the 'Set Default Values' param. Does that work?

In some moment of time, when I created USD file from alembic, I mentioned smaller file size. I read .usda file, and find in files from "Sop Import" time sampled visibility and extent(bound) which are the root of the problem.

Yes, I use this parameters in many combinations. With Topology Attributes and others too. And it don't work. But, for consistency, try again and it works. Add "visibility bounds" do the trick. I don't no why now its works, but who cares.

Thank you!!!

Maybe adding Cache Lop and separate static/animated geometry can replace using alembic and "Load Layer For Editing", but it need more testings. (I about node time dependency = recalculation nodes every frame. Alembic + "Load Layer For Editing" = animation but without time dependency in node tree)

tachbek
Maybe adding Cache Lop and separate static/animated geometry can replace using alembic and "Load Layer For Editing", but it need more testings. (I about node time dependency = recalculation nodes every frame. Alembic + "Load Layer For Editing" = animation but without time dependency in node tree)

Right, loading a usd layer (alembic or not) doesn't require a time dependent node because the node doesn't need to recook to obtain new values. The new values are obtained at a lower level - by usd, from the file contents. Like you said earlier, usd is simply holding a list of time sampled values that have already been (pre) computed. Sopimport or houdini key frames on the other hand need to be evaluated frame by frame, because there's no precomputed list, hence the time dependent node. It is a little confusing but hopefully that makes sense. Either way, I don't think you need to write your sop data out to alembic for it to be optimal in lops. However, if you wrote your sopimport out to usd that is probably going to be more efficient than cooking the sop network over and over.

antc
Right, loading a usd layer (alembic or not) doesn't require a time dependent node because the node doesn't need to recook to obtain new values.

Wrong.
When "Sop Import" samples sop node without animation, he is not time depended. But if he sampling other node with animated transformation, he become time dependent, and sample geometry each frame as static (= recompute himself each frame)

In other hand, if I saved this geometry as alembic and put in "Load Layer For Editing" Lop, this node not time dependent, but still produce animation.

When USD_ROP save animated data, he create separate "static file" in memory for each frame, and merge them in clever way.
Each frame cooks in sop level, then in "Sop Import" (because input change each frame) and down in Lop tree. Each frame Sop - Sop Import - Lops. And this relatively long.

In alembic case, animated data already precomputed (I guess) and Lop nodes tree works without time dependency = nothing too cook each frame = fast Lop workflow = very fast file saving time.

I suppose when "Sop Import" have animated input, he become animated because "don't knows", this is simple (packed) transform = put this in xform and done, or this some deforming mesh = need save geometry data each frame. He simply sampling each frame, because caching all input its too danger.

Now my Sop vs alembic dilemma exist just for reducing amount Lop nodes with time dependency. And now I will do some tests - can Cash Lop replace precomputed alembic animation .

For clarity. In Lop, I separate animation and time dependency, because (not like in sop) node without time dependency can produce animation, and you get different result each frame (but node not time dependent).
Image bellow. Two node produce identical scene graph tree and animation when you scroll timeline, but left one it's alembic from input in right node. (see time dependency icon)

tachbek
Wrong.
When "Sop Import" samples sop node without animation, he is not time depended. But if he sampling other node with animated transformation, he become time dependent, and sample geometry each frame as static (= recompute himself each frame)

In other hand, if I saved this geometry as alembic and put in "Load Layer For Editing" Lop, this node not time dependent, but still produce animation.

Yes that's correct. I think we're saying the same thing in different ways

1) As you've more or less discovered, the answer is "caching". You can cache to disk (as an Alebic or USD file, though I'd recommend USD), or you can cache in memory (with a Cache LOP). Caching to disk uses disk space and needs to be manually refreshed when things change. Cache LOP regenerates the Cache automatically when something in SOPs changes, but you pay the cost of cooking all those frames every time you load the hip file. You'll have to pick which caching solution works best for you.
2) As always, the fewer nodes that are time dependent, the less cooknig that happens on each frame, so the faster things will be moving frame to frame. In the specific case of material assignment, you have your geometry, you have a material library LOP to author the materials, and a Material Assign LOP to assign the materials to the geometry. Of those three nodes, only the geometry and material assignment need to be in the per-frame cook path. The Material Library can be "Merged" in with the geometry. The Material Library LOP can be particularly expensive to cook, so it's a good idea to keep it out of the time dependent cook chain. See the attached image. The right hand set of nodes should be faster.
3) The SOP Import LOP has a Parameter called "Set Default Values" for controlling which attributes should be authored as time samples, and which should not. Ther is also the "Topology Attributes" parameter specifically for controlling whether topology attributes should be authored as time samples or not.

And for the record, I don't think you and @antc are disagreeing about the behavior of SOP Import vs Load Layer to load an Alembic file. I read both of your descriptions as saying the same thing, and I agree with what they are both saying. But maybe it's me who is not understanding what one or both of you have written...

mtucker
And for the record, I don't think you and @antc are disagreeing

It's my fault, I misunderstood what he wrote.

1) Yes, USD file also not time depended
2) Good and simple solution
3) Yes, it's helps

Thanks for your reply! You helped a lot