Jump to content

antc

Members
  • Content count

    3
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About antc

  • Rank
    Peon

Personal Information

  • Name
    Antony
  • Location
    United States
  1. 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.
  2. 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.
  3. 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)
×