Solaris Reveal

[carlo_c]

Hey all, 

Saw there was no topic for this so figured I'd just make one to see what everyone's thoughts/opinions are on it now it's been officially announced. Personally quite excited to see it out and start using it, Karma looks very interesting. Quite a lot of USD concepts to ingest, seem slike there' s a slightly different name for everything 

Carlo

 

 

[Lutojar]

I think it's too early to discuss - need to test it first. But in general - for several years I wanted to give Katana a try in production, but didn't have a time to do it. That obviously looks like sometheng that can make Katana (or Clarisse builder) completely unnecessary to waste my time on.

And also reveal of Karma renderer explains why there was almost no development on Mantra in the las 2-3 years

[vhalldez]

Its is nice and extremely useful...I jusr desagree it to be a context and not a separeted software.

[vhalldez]

Correct me if I wrong, but with Solaris the ROP, ShOP, MAT, SOP, all will be unnecessary, everything doing into same context, right?

For me separeted contexts is inportant...Solaris should me another solftware as PillotPDG.

[malexander]

2 hours ago, vhalldez said:

Correct me if I wrong, but with Solaris the ROP, ShOP, MAT, SOP, all will be unnecessary, everything doing into same context, right?

For me separeted contexts is inportant...Solaris should me another solftware as PillotPDG.

If all you're doing is manipulating assets that are on disk, then you probably won't need to leave LOPs much. But you can also import objects, sops, and dops into LOPs, use SOPs to generate geometry, and VOPs to generate shaders as well. These tasks are still done in their own contexts, though sometimes within a LOP itself (eg, the Point Instancer LOP can contain SOPs, so it doesn't feel like you're jumping to another context as much). Having it as part of Houdini gives you a lot of flexibility that you wouldn't otherwise have in a separate application.

Because of the way USD is structured you can edit any asset in the scene with a LOP. So that asset might originate as a file on disk, be generated within LOPs (lights, cameras, simple geometry like a cube), or from SOPs, but once it's pulled in, you can non-destructively edit it with LOPs. So in that sense, you can edit everything in the same context, LOPs. Hope that clarifies things a bit.

[vhalldez]

2 hours ago, malexander said:

If all you're doing is manipulating assets that are on disk, then you probably won't need to leave LOPs much. But you can also import objects, sops, and dops into LOPs, use SOPs to generate geometry, and VOPs to generate shaders as well. These tasks are still done in their own contexts, though sometimes within a LOP itself (eg, the Point Instancer LOP can contain SOPs, so it doesn't feel like you're jumping to another context as much). Having it as part of Houdini gives you a lot of flexibility that you wouldn't otherwise have in a separate application.

Because of the way USD is structured you can edit any asset in the scene with a LOP. So that asset might originate as a file on disk, be generated within LOPs (lights, cameras, simple geometry like a cube), or from SOPs, but once it's pulled in, you can non-destructively edit it with LOPs. So in that sense, you can edit everything in the same context, LOPs. Hope that clarifies things a bit.

Sure...probably that will be my workflow..as you said.

[Lutojar]

7 hours ago, vhalldez said:

Correct me if I wrong, but with Solaris the ROP, ShOP, MAT, SOP, all will be unnecessary, everything doing into same context, right?

For me separeted contexts is inportant...Solaris should me another solftware as PillotPDG.

the whole point is to have it inside houdini - you could switch to other contexts anytime to do their own stuff. This is actually main killer feature over Katana/Clarisse - you could use everything houdini can do anytime and easily get what you need into LOPs.

It is huge simplification, of course, but you could treat new TOP context as new, more powerful version of the ROP context, and LOP could be thoughtof as new waaaaay more powerful OBJ context.

 

Edited August 2, 2019 by Lutojar

[Lucy Coleclough]

It may just be early ignorance but I do feel like lops being a whole new context is unnessasary. Things like the treatment of assets as a concept e.g. books is something that can already easily be done, albeit within a folder structure as opposed to one singular usd file. Didn't they show that off for tops by pulling a bunch of flower assets?. Other things shown off are also already possible with perhaps more flexibility, such as assigning a shader or shader parameter based on point or primitive attributes.

10 minutes ago, Lutojar said:

LOP could be thoughtof as new waaaaay more powerful OBJ context.

 

In this case I would much rather they integrate the new features of solaris, namely usd and the lighting improvements (which do seem very significant), into the obj context. Having two networks that kinda do the same thing but kinda don't seems redundant, leads to confusion and potentially may lead to data transfer issues. I also would like to see them expand on tops more. I think there's currently a lot of missed potential.

[CinnamonMetal]

LOP`s is quite impressive, layers etc.  Allows editing and control, if it`s the way I always imagined to work; then it will be great.

Edited August 3, 2019 by CinnamonMetal

[antc]

5 hours ago, ColecloughGeorge said:

In this case I would much rather they integrate the new features of solaris, namely usd and the lighting improvements (which do seem very significant), into the obj context. Having two networks that kinda do the same thing but kinda don't seems redundant, leads to confusion and potentially may lead to data transfer issues  

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)

 

 

Edited August 3, 2019 by antc

[Lutojar]

seems /obj is getting to be more of a rigging/animation context now

[Midphase]

1 hour ago, Lutojar said:

seems /obj is getting to be more of a rigging/animation context now

Exactly, that's the way I interpreted it speaking with the demo guys at Siggraph. Basically we're seeing a transformation of the /obj context from a geometry AND scene building context to predominantly a geometry building and animation context. 

The idea that I can work on my assets in /obj, do all my texturing, animation etc. there, and then jump into LOPS to bring everything together and work in a very optimized way makes 100% sense and I'm glad that Solaris isn't a separate application which would negate most of the benefits of the workflow that H18 is proposing. 

What we are witnessing is SideFX re-inventing VFX and CGI as we know it. While Maxon is busy improving bevels, and Autodesk is busy revealing their version of the Houdini Indie license, SideFX is completely re-imagining the CG pipeline with PDG earlier this year, and Solaris in a couple of months. 

Most people won't even quite realize what is happening until in a couple of years it will all click into place (perhaps with some yet undisclosed newer SideFX offerings that they're probably busy preparing right now). It's like a very clever Chess strategy, with seemingly unrelated moves that ultimately come together beautifully and check mate the competition.

Watch and see....

[flcc]

31 minutes ago, Midphase said:

While Maxon is busy improving bevels, and Autodesk is busy revealing their version of the Houdini Indie license

And Maxon also busy revealing their version of the Adobe-Autodesk license !

Yes it's very pleasant to be here and see real innovators at work.

Edited August 3, 2019 by flcc

[jordibares]

4 hours ago, Midphase said:

Exactly, that's the way I interpreted it speaking with the demo guys at Siggraph. Basically we're seeing a transformation of the /obj context from a geometry AND scene building context to predominantly a geometry building and animation context. 

The idea that I can work on my assets in /obj, do all my texturing, animation etc. there, and then jump into LOPS to bring everything together and work in a very optimized way makes 100% sense and I'm glad that Solaris isn't a separate application which would negate most of the benefits of the workflow that H18 is proposing. 

What we are witnessing is SideFX re-inventing VFX and CGI as we know it. While Maxon is busy improving bevels, and Autodesk is busy revealing their version of the Houdini Indie license, SideFX is completely re-imagining the CG pipeline with PDG earlier this year, and Solaris in a couple of months. 

Most people won't even quite realize what is happening until in a couple of years it will all click into place (perhaps with some yet undisclosed newer SideFX offerings that they're probably busy preparing right now). It's like a very clever Chess strategy, with seemingly unrelated moves that ultimately come together beautifully and check mate the competition.

Watch and see....

Indeed, we are witnessing something that is going to revolutionise Computer Graphics and your checkmate analogy is spot on.

[Lucy Coleclough]

19 hours ago, antc said:

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)

 

 

Whilst I agree that lops does bring many big improvements, I don't think that justifies building a new context seperate to obj. I don't know much about how it works under the hood but I'm sure it's not impossible to generate usd data from the current obj nodes, then add the new lighting and shading features in the mix. Why would rigs be cooked if they're hidden? And if they aren't hidden then there's no way around cooking them, you will always have that overhead.

We already have an asset configuration context and two export contexts.

I love sideFX and their work but I think this is a tad sloppy. Either add the new features to obj or just remove obj in favour of lops.

[antc]

59 minutes ago, ColecloughGeorge said:

Whilst I agree that lops does bring many big improvements, I don't think that justifies building a new context seperate to obj. I don't know much about how it works under the hood but I'm sure it's not impossible to generate usd data from the current obj nodes, then add the new lighting and shading features in the mix. Why would rigs be cooked if they're hidden? And if they aren't hidden then there's no way around cooking them, you will always have that overhead.

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.

[anim]

5 hours ago, ColecloughGeorge said:

We already have an asset configuration context and two export contexts.

I love sideFX and their work but I think this is a tad sloppy. Either add the new features to obj or just remove obj in favour of lops.

give it some time, every new technology needs to mature, also having overlapping contexts during transition period is not sloppy but very smart, if TOPs are gonna replace ROPs this can't happen over night, so having them in parallel can help the transition, also backward compatibility and artist knowledge needs to be considered. You simply can't just remove a feature or entire context with a snap and expect everyone to be up and running with a completely new set of tools just like that

LOPs and Obj don't necessarily overlap 100% so I can see them both taking a specific path in the future rather than one being removed

also I'll always prefer to have a choice between 2 ways to do something rather than 0

[mestela]

8 hours ago, ColecloughGeorge said:

Whilst I agree that lops does bring many big improvements, I don't think that justifies building a new context seperate to obj. I don't know much about how it works under the hood but I'm sure it's not impossible to generate usd data from the current obj nodes, then add the new lighting and shading features in the mix. Why would rigs be cooked if they're hidden? And if they aren't hidden then there's no way around cooking them, you will always have that overhead.

We already have an asset configuration context and two export contexts.

I love sideFX and their work but I think this is a tad sloppy. Either add the new features to obj or just remove obj in favour of lops.

Have you tried to light a non trivial shot in /obj context? Myself and a bunch of lighters suffered through this on HF2, it was awful. /obj is fine for a handful of nodes, but these days production lighting setups involve hundreds, thousands of assets. It's the kind of problem USD was built to address. Further, katana showed the way forward with a 'high level node based stream of all the things', the existing object framework was never going to be able to deal with that efficiently.

 

 

[Lucy Coleclough]

14 hours ago, antc said:

 

10 hours ago, anim said:

 

7 hours ago, mestela said:

 

Fair points. I don't think I was considering big scale production as much as I'm currently a student. Backwards compatibility is always a concern as well.

That said, I would still like to see obj become purely rigging in the future if it can't be integrated into lops, and modelling moved into lops as I think the ability to model in the layout context is quite intuitive. Also being able to easily use data from cameras and lights in your sop trees is useful.

Didn't mean to come across ungrateful, this software is still leaps and bounds better than anything on the market.

Edited August 4, 2019 by ColecloughGeorge

[carlo_c]

On 04/08/2019 at 8:04 AM, mestela said:

Have you tried to light a non trivial shot in /obj context? Myself and a bunch of lighters suffered through this on HF2, it was awful. /obj is fine for a handful of nodes, but these days production lighting setups involve hundreds, thousands of assets. It's the kind of problem USD was built to address. Further, katana showed the way forward with a 'high level node based stream of all the things', the existing object framework was never going to be able to deal with that efficiently.

 

 

This is what I'm really looking forward to, efficient lighting of scenes involving hundreds of lights and assets. It's really become commonplace now, and with now pretty much all render engines having transitioned to path tracing it's now much harder to use some of the old tricks for "faking it".