Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

1 Neutral

About antc

  • Rank

Personal Information

  • Name
  • Location
    United States
  1. Similar to Alembic, there is a USD packed primitive that can be used to represent USD in sops. The packed prim workflow has been around for a while now, prior to lops - it just never shipped as standard with Houdini. I believe the lopimport sop takes prims from the lop stage and populates them in the sop geometry network as USD packed prims. From there they can be unpacked to regular houdini geo, have their attributes modified, etc. I’d expect geometry going back and forth between lops and sops to be pretty fluid and full-featured. Less so obviously for other types of scene data such as materials and lights which don’t belong so much in sops.
  2. If by “OUT context” you mean render in mantra then the answer is no that’s never going to be possible because mantra takes IFD as input, not USD. Also, lookdev will typically be tied to whatever (Hydra compatible) renderer you are using. E.g lookdev done in Karma would not be meaningful to RenderMan (USD preview surface being the possible exception there). Are there specific workflows you are looking for?
  3. Karma benchmark

    Karma is brand new and currently in beta. I’d say comparing to established renderers at this point would seem a little unfair.
  4. Solaris Reveal

    Usd has native support for referencing alembic files (via a file format plugin). Therefore my guess would be that lops supports referenced alembic too. So in theory you could use lops to assemble abc caches in the traditional way and still get some of the typical usd benefits like sparse overrides etc. Studios that still maintain their own cache format can write a file format plugin if they wish, similar to how Pixar have done for alembic.
  5. Solaris Reveal

    Yeah I see what you are saying but under the hood obj and lops are worlds apart unfortunately. When two nodes are connected in obj it simply implies parenting. When a obj node cooks it is expected to produce a transform. In lops there's an entire usd scene flowing through the wires. When a lop node cooks it modifies the scene in some way, potentially thousands or millions of objects all at the same time it would seem. Exactly what a lop node modifies can presumably be anything in the scene. That's very different from from an obj node that sets a transform. Typically a rigging context would want to be concerned with moving a bunch of transforms and points rather than wrangling scene graphs with materials, lights and render settings. The way to get around cooking rigs is usually to bake the transforms and points into a cache like bgeo, alembic, usd etc. In fact most rigs these days have simulations at some point that may take hours to cook (depending on the length of the shot) so baking is the only practical option. Btw usd has been available in obj for quite a few years via usd packed prims. They are similar to the alembic packed prims that ship as standard with houdini. The problem is you don't really get any benefit from all the features available in usd like referencing and layering. Sure usd packed prims work as a cache format but then so does alembic and bgeo.
  6. Solaris Reveal

    The thing with /obj, other than it not being procedural, is that it’s impossible for it to scale to massive scenes. /obj is basically too powerful (cooks for rigging etc) to work with millions of objects/assets. Usd on the other hand is considerably lighter (no ‘cooking’ as such) and so naturally has a higher upper limit, easily into the millions with current hardware. Typically in a scene with millions of assets the majority of them are static or baked, in which case /obj (and sops) buys you very little (particularly if you’re a lighter!) Scenes described predominantly as Usd in lops with all the import/cool stuff cherry picked from /obj, sops and dops then injected into lops really does give the best of both worlds in my opinion. The other huge thing of course is that /obj is houdini specific. Usd on the other hand is universal A big part of lops beyond lighting is as an asset configuration and export context that can then be consumed in any application that supports Usd (including back into houdini)