学荣 陈

mtucker
Have you tried turning on the (relatively new) "All Clip Files Have Matching Scene Graph Structure" parameter? Enabling this option should prevent the geo clip sequence LOP from having to open all the clip files in order to author the clip data (it normally has to check all the clip files in order to build the manifest and topology files). Turning off "Flatten Clip Files" (if you know this step isn't necessary, as it would not be for BGEO clip files because they don't support composition) can also help improve the performance of this node.

But to work this way, you are responsible for ensuring that the scene graph structure is not changing over time and that the clip files don't need to be flattened.

Yes, I have taken care to ensure that these problems do not occur, the scene graph structure is not changing over time, the problem still exists

mtucker
The answer to your question is "the geo clip sequence LOP". If it's not working as expected, or not generating results that work for you, then please provide some kind of example/demo file that shows this happening. This is the intended and expected workflow, so if it's not working, we'd like to fix it.

Loading a properly structured value clip into a scene should not cause all the clip files to be opened at once. And the geo clip sequence LOP should always be authoring properly structured value clips.

I did notice you saying that you sublayered the value clip file into your scene, which is a bit unusual. Generally when working with value clips I've seen the referenced onto a stage rather than sublayered. I don't think that should matter, but it might be worth testing...

I did some tests on storing valueclip, using the 20.5 version of the geoclipsequence node.
This is the problem I encountered many times in my tests:
If you directly use an existing file (bgeo or vdb) to link, when loading the valueclip, all the linked files will be read once before refreshing the data in the window.
Only after turning on Flatten Clip Files and regenerating the existing geo into a usd file, the read valueclip file can be read correctly according to the corresponding frame number. It will not read all the cache at once.
The same problem occurs when using sublayer and reference nodes
It is recommended to use a large cache to test, so that you can intuitively see that the hard disk reading speed is completely different.
I have also tested it on many machines and with the 20.0 version.
Is there any other way to solve this problem?

eikonoklastes
If you Ctrl+MMB to get the persistent info window, you can then resize that window to be wider. This setting will then later be inherited by the temporary MMB popup (even if you close the persistent window), so you get more flexibility with how you want that to display.

Adjusting the width may allow one or two more attributes to be displayed in one row, but if there are a large number of attributes and vdb together, you always have to manually pull the scroll bar.
I still don't understand why the vdb and volume display has to be changed like this. The old version can display all the corresponding data in one row. The current one takes up such a large range.
The node info displayed by MMB should show the operator the most information about the node attributes. I think it is too bloated now. It is a good thing to update the UI, but most of the usage scenarios must be considered. At least the artists around me would rather choose to use the old one. I hope sidefx can optimize these parts later.