Egor Chashchin

Btw. Arnold7 uses now USD files as scene description and with good degree of success. Yes, there is render delegate, but I hope SideFX will split Karma execution to same branches.

You are all right, that it is still developing. But it is developing sensible big amount of time - and doesn't demonstrate still convincing "reasons d'etre".
It is timing about two months of qualified developer to implement renderer adon, which can translate USD data to renderer's API calls. With much more wider range of features supported. All renderer's API's (production used) have similar patterns and subjects of processing. If you need task-oriented extending - ok, you just implement it too, as you will do it for renderer delegate. OpenNSI demonstrates some modern approach and don't offer itself to be "common biggest divider".
I seem Hydra is strange branch of rib-filtering idea, but we used rifs for extending content interpretation, instead of cutting it dramatically.
Very interesting - when Pixar themselves get usd file for rendering - do they really use Hydra? They offer such feature. Do they really cut everything not fitted to hydra pipeline from THEIR renderer? And what customers said about this situation?
All noise, I make is not about defective geometry - I hope it will fixed sometimes - (but H19 will render for you squashed 90-faced eggs instead of spheres while) - now I prepare for possible whole production pipeline and I should explain why "we can/cannot use such modern and fast renderer". And now I faced that I cannot said any calming words. Should we thought about Solaris workflow of go pray for Katana (yes, it used hydra for preview, not more). Or just go and spend two months for translator. (Tamerlane forces his sons "learn languages of provinces you rule - then translators could not lie you".) What else and in what worst of possible moment I will found, that something always known as effectively and robust working - will "just not implemented still"?
I mentioned NVIDIA before - I seem it explains disbalance with USD and Hydra developing - just because NVIDIA uses USD and forces it's development - and they were not interesting with Hydra per se - RTX driver uses it - but they changed sources, so it is incompatible with main developers branch.
Let there be Hydra ZOO! Why not another for SESI too? I can develop another one too, if someone ask.
May be it is simpler just to feed one head we needed then?
(Very interesting, do they have squashed spheres in omniverse marbling demo, or didn't noticed such fact? Or they see this and didn't warn anyone and just threw this primitive from using?)

SO, it obsolete before it was born. Ok, then why SESI pay so much attention to it? it is absolutely independent story form usd - and nothing forced them to build newest and modern renderer over such strange and obviously restrictive rendering mechanics. I know about 6 render delegates published, and just one scene delegate - usd delegate. To be true - no more required since usd is really cover most needs as data storage / interpretation and access technology. 18 years ago we developed XML-based group of technologies dedicated to same purposes - produce and transform scenes for renderman - so I was very glad, that we found a lot of similar approaches and concepts in usd later. And now I try to use usd as a data exchange format for a lot of research projects - and even usdviewq widget for analyzing of results (and I spend a lot of time uderstanding why I see skewed geometry, for example, and it was not a dynamic engine failures) - and I was disapointed, that If I decide to push more complex structure to renderer - for example -tetrahedral meshes - I should go to usd sources to implement its adapter - even if I've already implemented such type as usd-scheme. Anyway then I will gen to render not that data I've dealt with in scene.
And last. Hydra is renderer proxy layer. But why we decide, that rendering - is just convert geometry to raster busfers? Wat about vector layers? Is physical simulation - a rendering process too? Why not? Better for Hydra to be analog of XSLT technology, rather than WebGL, then it has practical potential.
Very interesting - since nvidia so wildly uses usd with its omniverse - does it pay so much attention to hydra too?