Solaris Reveal

[willow wafflebeard]

so does this mean /obj could potentially be animation/rigging context and LOP will be that topmost level, where people can collaborate?. can't help but notice that LOPs does  mostly the same as /obj but just has a more potential for proceduralism. why not omit /obj entirely and replace it with LOPs,  animation and rigging context can go to CHOPS.. if so does this mean that .hip will be replaced by usd?. SESI is really having me clueless of the future, but its exciting.

[Outlawed]

Correct me if I'm wrong, but when Solaris is released, the only studios who can use it are ones that have a USD-based pipeline (Animation, not just assets), and intend to use Renderman?

Mantra hasn't had any development, Karma will be in Beta, and any other Houdini-supported render engines will need to have their Hydra delegates working in Solaris.  Am I getting this wrong?

[malexander]

13 hours ago, Outlawed said:

Correct me if I'm wrong, but when Solaris is released, the only studios who can use it are ones that have a USD-based pipeline (Animation, not just assets), and intend to use Renderman?

Mantra hasn't had any development, Karma will be in Beta, and any other Houdini-supported render engines will need to have their Hydra delegates working in Solaris.  Am I getting this wrong?

 

A third party render engine just needs to have a render delegate for Hydra. There's nothing special to get it running within Solaris or Houdini. If it works outside of Houdini, it'll work within it.

[Outlawed]

But the USD issue still stands.  Or can it take .abc and internally convert it on the fly?

[Mandrake0]

1 hour ago, Outlawed said:

But the USD issue still stands.  Or can it take .abc and internally convert it on the fly?

Hydra is a defined API for render engines / viewport. If a render engine has a hydra implementation it can be used in houdini / katana and any tool that has hydra API implemented. It will just need USD no .abc but you can add a custom filehandler addon if required. I would say .abc will be obsolet with USD.

[antc]

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. 

Edited September 6, 2019 by antc

[Andrea]

As they said you can take objects from /obj context and import (and probably also convert automatically) for LOPS. So I don't think is going to be a problem at all to have different file formats.

[malexander]

On 9/5/2019 at 12:52 PM, Outlawed said:

But the USD issue still stands.  Or can it take .abc and internally convert it on the fly?

You can import Alembics directly into USD, so yes, it can take .abc and convert it on the fly.

[sebkaine]

On 03/08/2019 at 6:16 PM, Midphase said:

 ... that ultimately come together beautifully and check mate the competition.

Watch and see....

I hope not  !

Competition is great for us, I don't want to see SESI becoming the new Foundry. When you have a full monopoly on your market you always tend to slide slowly to the dark side of the Force.

However it would be a delight to see SESI competing against Foundry monopoly on the high end compositing software market.

[Lutojar]

- redshift already has hydra delegate in work, probably ready somewhere near h18 release.

- vray gatting there too

- renderman already supported

hope karma will be in a good shape enough

 

as about renderman - even Blue Sky switched to renderman because of solaris. Blue Sky - guys who has their own reaytracer renderer for decades. Even more: Marcos Fadjardo once said he got the idea of arnold renderer after seeing some pictures rendered by that renderer from Blue Sky. and now they are using renderman.

Edited September 10, 2019 by Lutojar