If this video helped maybe consider tipping on tipee ! Any donation is appreciate and really help support the channel 😃 Detailing in this page my goals here and how anyone can contribute 🙏 Cheers ! en.tipeee.com/adrienlambertvfx
just a warning to anyone wanting to try out USD as a pipeline, its still really buggy and crashes quite a bit. One major hurdle that we couldnt get over was that scenes would crash all the time once they became complicated enough with 50+ assets scattered around. In theory it is amazing (watch sidefx's magic market videos), just need to wait for it to be more stable!
I think that largely comes down to how you are dealing with it, your chosen DCCs, target renderer, and general pipeline experience with USD. I've used it since 2015 at Method Studios on large scale projects with 10s of thousands of assets/objects. It is not for the faint hearted, but I don't agree about the stability observation you have.
@@lewistaylorFX yeah ive heard usd works great in larger studios with proper pipeline devs, im talking more for small teams without that support however id be keen to hear more from you if im wrong!
Still buggy, but our student team is actually getting it to work quite well with version Houdini 19.0! It is very possible but takes a lot of patience and work.
Great intros to usd and solaris, probably the best I have found so far in regard of basic understanding what the workflow could do. It is a game changer from look dev to complex lighting scenes with tons of shaders, geos, simulations ect. It does have the potential of being UE for the VFX with almost limitless possabilities. USD is pretty stable so far and if the context described here is properly applyed to a scene it should not give major errors and crashes. Of course USD is still under development both sideFX and Pixar commercially push hard at that direction. Thank you Adrien for the efforts to bring your understanding of how it works!
I should have watched this way earlier. There was so much stuff about the USD workflow that I didn't really understand, but this made it click. Thank you! Excited for the other videos.
Thanks Tim ! Glad if it helps, hopefully I'm not 100% wrong lol When I think I understand something there's always something else that gonna makes me question it xD
@@AdrienLambertvfx that's how I also feel when explaining stuff xD but you did a great job with this. Got a question btw, is the reference lop in 19.5 (the 2.0 version) broken that you know of, or am I missing something. Everything seems to work fine with the 1.0 version of the asset, but 2.0 breaks it. I feel this is also why qbridge isn't working fore 19.5. I feel like like it might be a bug but perhaps i'm missing something. All of the nodes that use a nested version of reference lop seem to use the 1.0 version as well.
Ah but nothing would have 'clicked' if you hadn't jumped in and started trying to do it! This is one way I've learned to learn things. Study until you really want to dive in, run into a bunch of problems then go back to study them and it will 'click' and be cooked into your brain
@@TimvanHelsdingen Oh that's an interesting flag, tbh haven't used the reference lop enough to really notice any major bug, but could be likely yeah. I'll try pay attention next time I use and will let you know. ;)
Very deep Solaris and USD lections and workflow. Thank you Adrien! Currently it start to take more attention to it, as it become production ready in Houdini.
I think in 19.5 they added the possibility to select geo for pruning without the need to change the KIND on the geo path hierarchy. Great resource by the way, thanks for putting this together.
Hi Adrien, i have on question, if I create a clothing sim in houdini and create all my texture in substance painter and exported the texture as USD from painter, how it works? I have import my usd geo in solaris but my clothing sim if already here in sop?
is there a trick to getting the configure primitives to work for proxy or render? I have tried with one basic setup and it works nicely just for a simple sphere yet for a terrain it shows both render and proxy
Hi Adrien, i'm a Clarisse widow learning my ways into Solaris, read the documentation in houdini website, watched your videos, amazing how you trickled down the documentation, but i'm struggling with the Houdini side of things, like when you switch to preview/render modes when explaining proxys and such, or when you switch from opengl to karma(path tracer)... Those things you only know when you're familiar with the software. My question is, being a Clarisse user, switching to Solaris, how do i approach this with 0 knlowedge in houdini? Should i learn it first? From where? Can you recommend me a course or youtube channel/videos?
Hi ! Learning Solaris can be tricky without having Houdini fundamentals for sure. Mostly because those two are very inter-twined especially for scattering or dealing with content creation. sidefx got great tutorials to start to be honest. No need of looking at particles, simulations tutorials if it's not your goal. But understanding how houdini operate with attributes, groups manipulation will be usefull in both solaris and houdini obj networks. I may make a video about effective way to learn since it remains a scary step for lot of new users who wanna approach houdini.
Is Solaris at a level where it can do Clarisse-scale shots with trillions of polygons? Also curious about scattering and assembly parity. Looks like Clarisse may have been discontinued so looking for a path forward. Solaris seems to be the way.
Solaris can handle a lot I guess in terms of polycount and instancing amount, but would say you'd still need to pay attention to optimization otherwise your viewport may get very slow. What's cool is you can create proxy for viewport and let render load highres geo, if you go solaris road that would be important to consider. (and would say that would be the case whatever software you use, only Clarisse has such raw power for viewport performance. )
Hello, very nice tutorial. At some point you changed your sop import to point instancer making it more optimized for instances. Is there a way to do this with an extrernal usd made in another dcc? For example when I bring a tree from blender that support usd instances it takes a lot of time to load and it seems not right. Can we change this inside lops or we must go through /obj?
If you load most assets as reference do you have "unlimited polygons" like in UE5 Nanite or Clarisse ? Since afaik Clarisse has no polygon limit because everything is reference and not loaded into the project/software itself so you can lets say import a 1Mil poly building, duplicate it trillion times and it will just use the resources of a single building so it's way better than instancing or proxies.
In theory yeah, it does leverage instancing allowing creation of heavy scenes. I would still generate a proxy purpose for my USD as otherwise display still get fairely limited in viewport. (most instances would turn to box passed 50 millions poly). This won't beat Clarisse in terms of viewport performence, but rendering would be quite fast.
How common is using 'multi-shot' in Solaris? They are at my studio and it's an absolute nightmare. I'm also thinking couldn't that have been done in old Houdini just as well? ( Taking dozens of vfx shots that can use the same light rig, and making 1 artist light them all at once )
Multishot in obj requires a lot of energy. It becomes hard to track and manage per shot/sequence changes compared to simply authoring stronger opinions to the USD stage.
@@lewistaylorFX Authoring stronger opinions is not 'lighting' ; every shot is different - unless you're lighting for Bratz or some other kid's show - even if the camera doesn't move. You get notes per-shot, do you then update all the similar shots and re-render them? No ofc not. So you end up with different lighting in each shot. You get different fx and animation per shot - that changes the lighting needs of each one... again, on a per-shot basis. Your Shotgun tasks to keep track of, are per-shot. And there's 3-4 times more than you ever had before. Light comps are per shot. And again 3-4 times more of those than ever. So all that USD does so far is save a LITTLE time on *One* of a lighter's Four basic tasks ( Lighting, Light-comping, Asset importing/updating, Wrangling SG and farm renders ) all of which have been otherwise *tripled*. Does production give you 3 times as many days to complete the shots? No ofc not, that's the whole point of this crap, to squeeze blood from a stone ( and the artists ). Will we have Anim, FX and Comp do multi-shot too? No ofc not. But Lighting is just like digging ditches. It either works or it doesn't. This is the dumbass mentality I've been noticing the last couple years. Except that any decent VFX - who usually come from Comp - expects everything to perfect, *and* work perfectly in the comp.
@@schmoborama USD encompasses more than the simple bit I mentioned, or what you've touched on. What Studio do you work at? I've been using it for several years, it has changed the way we work. As far as sequence lighting, well that absolutely happens in Solaris, Katana, Gaffer. FX absolutely does multi-shot, no idea where you are getting the notion that FX doesn't. Comp also, if it's elements updating, across a sequence they are all multi-shot updated and pushed to Shotgun automatically as WIP updates to inspect. Your rants about the workload, I don't disagree, there's a lot expected now, but that is a separate issue to USD. The benefits are huge, in terms of data on disk, IO, updating sequences without needing to even open your houdini, Maya, Katana scene because the USD stage takes those overrides, etc. Maybe the Studio you work at has no idea how to use it properly?
@@lewistaylorFX Obviously it's more than just lighting, I'm not talking about what it does for IO, that shouldn't depend on whether lighting does mutli-shot or not ; and there's no point in improving one dept. at the expense of another. FX does multi-shot... in Solaris? Or in Houdini, just like they always have. Ofc if there's a building collapsing, they're not going to sim it per-shot. My point was that they still get per-shot notes, then export caches *per-shot*, which the lighter then updates *per-shot*. Same with anim. Comp is also not expected to color-correct, use roto or pull keys on a per sequence basis. They're not expected to do 3x more shots than before - why is lighting? Because of that dumbshit attitude, like a client's, that all lighters do is push a few buttons. - " that is a separate issue to USD" Er, Solaris, er, USD, er, Solaris/USD, er, no just USD, er, multi-shot ; why am I learning all this shit that does nothing but make lighting worse Yes, multi-shot, not USD. I could give a damn about USD if they just kept it in the background. I'd prefer no improvements to the lighting workflow, to this. It would be more profitable for the company too. My studio may or may not be doing it right, but regardless it's going to take another 6 months if not a year, just to get back to square one, to a point where the same number of shots can be brought up to the same quality on schedule. A year that could have been used to advance the previous pipeline. If you're going to tell me that USD is only good for the biggest studios, I'm inclined to agree. I appreciate your input btw.
If this video helped maybe consider tipping on tipee ! Any donation is appreciate and really help support the channel 😃
Detailing in this page my goals here and how anyone can contribute 🙏 Cheers ! en.tipeee.com/adrienlambertvfx
just a warning to anyone wanting to try out USD as a pipeline, its still really buggy and crashes quite a bit. One major hurdle that we couldnt get over was that scenes would crash all the time once they became complicated enough with 50+ assets scattered around. In theory it is amazing (watch sidefx's magic market videos), just need to wait for it to be more stable!
I think that largely comes down to how you are dealing with it, your chosen DCCs, target renderer, and general pipeline experience with USD.
I've used it since 2015 at Method Studios on large scale projects with 10s of thousands of assets/objects. It is not for the faint hearted, but
I don't agree about the stability observation you have.
@@lewistaylorFX yeah ive heard usd works great in larger studios with proper pipeline devs, im talking more for small teams without that support however id be keen to hear more from you if im wrong!
@@lewistaylorFX any tips to a junior USD pipeline TD?
Still buggy, but our student team is actually getting it to work quite well with version Houdini 19.0! It is very possible but takes a lot of patience and work.
@@lewistaylorFX
ofc 'USD' is not buggy, it's not software - that's clearly not what he meant
Great intros to usd and solaris, probably the best I have found so far in regard of basic understanding what the workflow could do. It is a game changer from look dev to complex lighting scenes with tons of shaders, geos, simulations ect. It does have the potential of being UE for the VFX with almost limitless possabilities. USD is pretty stable so far and if the context described here is properly applyed to a scene it should not give major errors and crashes. Of course USD is still under development both sideFX and Pixar commercially push hard at that direction. Thank you Adrien for the efforts to bring your understanding of how it works!
I should have watched this way earlier. There was so much stuff about the USD workflow that I didn't really understand, but this made it click. Thank you! Excited for the other videos.
Thanks Tim ! Glad if it helps, hopefully I'm not 100% wrong lol When I think I understand something there's always something else that gonna makes me question it xD
@@AdrienLambertvfx that's how I also feel when explaining stuff xD but you did a great job with this.
Got a question btw, is the reference lop in 19.5 (the 2.0 version) broken that you know of, or am I missing something. Everything seems to work fine with the 1.0 version of the asset, but 2.0 breaks it. I feel this is also why qbridge isn't working fore 19.5.
I feel like like it might be a bug but perhaps i'm missing something. All of the nodes that use a nested version of reference lop seem to use the 1.0 version as well.
Ah but nothing would have 'clicked' if you hadn't jumped in and started trying to do it! This is one way I've learned to learn things. Study until you really want to dive in, run into a bunch of problems then go back to study them and it will 'click' and be cooked into your brain
@@TimvanHelsdingen Oh that's an interesting flag, tbh haven't used the reference lop enough to really notice any major bug, but could be likely yeah. I'll try pay attention next time I use and will let you know. ;)
Very deep Solaris and USD lections and workflow. Thank you Adrien! Currently it start to take more attention to it, as it become production ready in Houdini.
This video is amazing. Cant believe that is a free contet. Thank you Adrien for this
Really awesome and detailed tutorial! Thank you very much!!
I'm questioning my existence after watching this video. Thank you mate. Need to watch it to let it settle down xD
Hahaha that feeling never actually go away when you explore usd/solaris some more lol
I think in 19.5 they added the possibility to select geo for pruning without the need to change the KIND on the geo path hierarchy. Great resource by the way, thanks for putting this together.
Thanks for an excellent tutorial Adrien, I am already looking forward to the next one!
thank you very much for this! really helpful intro to usd, cant wait for the next video
really helpful video and can't wait to watch the next tutorial of this series. Thanks~
this series is gold！ thanks for doing it！
Hi Adrien, i have on question, if I create a clothing sim in houdini and create all my texture in substance painter and exported the texture as USD from painter, how it works? I have import my usd geo in solaris but my clothing sim if already here in sop?
can't wait for part 2. Thanks for the info
What is the difference between instancing on the stage vs instancing in sops like this?
Thanks for your videos.
Very helpfull one.
Solaris / usd is the way !
Very Nice! Thanks!
Another Adrian Lambert gem.
Very helpful. Thanks!
been waiting for this one! thanks
Love this so much! Thank you!
is there a trick to getting the configure primitives to work for proxy or render? I have tried with one basic setup and it works nicely just for a simple sphere yet for a terrain it shows both render and proxy
using a sublayer between the two configure primitives seemed to do the trick
Hi Adrien, i'm a Clarisse widow learning my ways into Solaris, read the documentation in houdini website, watched your videos, amazing how you trickled down the documentation, but i'm struggling with the Houdini side of things, like when you switch to preview/render modes when explaining proxys and such, or when you switch from opengl to karma(path tracer)... Those things you only know when you're familiar with the software.
My question is, being a Clarisse user, switching to Solaris, how do i approach this with 0 knlowedge in houdini? Should i learn it first? From where? Can you recommend me a course or youtube channel/videos?
Hi ! Learning Solaris can be tricky without having Houdini fundamentals for sure. Mostly because those two are very inter-twined especially for scattering or dealing with content creation. sidefx got great tutorials to start to be honest. No need of looking at particles, simulations tutorials if it's not your goal. But understanding how houdini operate with attributes, groups manipulation will be usefull in both solaris and houdini obj networks. I may make a video about effective way to learn since it remains a scary step for lot of new users who wanna approach houdini.
super cool lesson!!! thank you so much!!!🙏
Merci beaucoup pour cette vidéo très excellente
Is Solaris at a level where it can do Clarisse-scale shots with trillions of polygons? Also curious about scattering and assembly parity. Looks like Clarisse may have been discontinued so looking for a path forward. Solaris seems to be the way.
Solaris can handle a lot I guess in terms of polycount and instancing amount, but would say you'd still need to pay attention to optimization otherwise your viewport may get very slow. What's cool is you can create proxy for viewport and let render load highres geo, if you go solaris road that would be important to consider. (and would say that would be the case whatever software you use, only Clarisse has such raw power for viewport performance. )
Thank u alot for this great tutorial
Thanks! Solaris is amazing.
thx man, it is good stuff
pretty helpful. Thanks
Agin really good tuts in the way u explain it
Thanks
Hello, very nice tutorial. At some point you changed your sop import to point instancer making it more optimized for instances. Is there a way to do this with an extrernal usd made in another dcc? For example when I bring a tree from blender that support usd instances it takes a lot of time to load and it seems not right. Can we change this inside lops or we must go through /obj?
If you load most assets as reference do you have "unlimited polygons" like in UE5 Nanite or Clarisse ?
Since afaik Clarisse has no polygon limit because everything is reference and not loaded into the project/software itself so you can lets say import a 1Mil poly building, duplicate it trillion times and it will just use the resources of a single building so it's way better than instancing or proxies.
In theory yeah, it does leverage instancing allowing creation of heavy scenes. I would still generate a proxy purpose for my USD as otherwise display still get fairely limited in viewport. (most instances would turn to box passed 50 millions poly). This won't beat Clarisse in terms of viewport performence, but rendering would be quite fast.
These videos are great, thanks for doing them! Are you going to be using Solaris for your future personal projects?
really helpful
Is confuse for my .. :(
Dude just use unreal lol
I do use unreal ;) My plan on long run is to get layout done in solaris and render in unreal or omniverse. Leveraging strength of both world.
@@AdrienLambertvfx great idea !!
How common is using 'multi-shot' in Solaris? They are at my studio and it's an absolute nightmare. I'm also thinking couldn't that have been done in old Houdini just as well?
( Taking dozens of vfx shots that can use the same light rig, and making 1 artist light them all at once )
Multishot in obj requires a lot of energy. It becomes hard to track and manage per shot/sequence changes compared to simply authoring stronger opinions to the USD stage.
@@lewistaylorFX
Authoring stronger opinions is not 'lighting' ; every shot is different - unless you're lighting for Bratz or some other kid's show - even if the camera doesn't move. You get notes per-shot, do you then update all the similar shots and re-render them? No ofc not. So you end up with different lighting in each shot. You get different fx and animation per shot - that changes the lighting needs of each one... again, on a per-shot basis. Your Shotgun tasks to keep track of, are per-shot. And there's 3-4 times more than you ever had before. Light comps are per shot. And again 3-4 times more of those than ever.
So all that USD does so far is save a LITTLE time on *One* of a lighter's Four basic tasks ( Lighting, Light-comping, Asset importing/updating, Wrangling SG and farm renders ) all of which have been otherwise *tripled*. Does production give you 3 times as many days to complete the shots? No ofc not, that's the whole point of this crap, to squeeze blood from a stone ( and the artists ).
Will we have Anim, FX and Comp do multi-shot too? No ofc not. But Lighting is just like digging ditches. It either works or it doesn't. This is the dumbass mentality I've been noticing the last couple years. Except that any decent VFX - who usually come from Comp - expects everything to perfect, *and* work perfectly in the comp.
@@schmoborama USD encompasses more than the simple bit I mentioned, or what you've touched on. What Studio do you work at? I've been using it for several years, it has changed the way we work.
As far as sequence lighting, well that absolutely happens in Solaris, Katana, Gaffer.
FX absolutely does multi-shot, no idea where you are getting the notion that FX doesn't.
Comp also, if it's elements updating, across a sequence they are all multi-shot updated and pushed to Shotgun automatically as WIP updates to inspect.
Your rants about the workload, I don't disagree, there's a lot expected now, but that is a separate issue to USD.
The benefits are huge, in terms of data on disk, IO, updating sequences without needing to even open your houdini, Maya, Katana scene because the USD stage takes those overrides, etc. Maybe the Studio you work at has no idea how to use it properly?
@@lewistaylorFX
Obviously it's more than just lighting, I'm not talking about what it does for IO, that shouldn't depend on whether lighting does mutli-shot or not ; and there's no point in improving one dept. at the expense of another.
FX does multi-shot... in Solaris? Or in Houdini, just like they always have. Ofc if there's a building collapsing, they're not going to sim it per-shot. My point was that they still get per-shot notes, then export caches *per-shot*, which the lighter then updates *per-shot*. Same with anim. Comp is also not expected to color-correct, use roto or pull keys on a per sequence basis. They're not expected to do 3x more shots than before - why is lighting? Because of that dumbshit attitude, like a client's, that all lighters do is push a few buttons.
- " that is a separate issue to USD"
Er, Solaris, er, USD, er, Solaris/USD, er, no just USD, er, multi-shot ; why am I learning all this shit that does nothing but make lighting worse
Yes, multi-shot, not USD. I could give a damn about USD if they just kept it in the background. I'd prefer no improvements to the lighting workflow, to this. It would be more profitable for the company too.
My studio may or may not be doing it right, but regardless it's going to take another 6 months if not a year, just to get back to square one, to a point where the same number of shots can be brought up to the same quality on schedule. A year that could have been used to advance the previous pipeline. If you're going to tell me that USD is only good for the biggest studios, I'm inclined to agree. I appreciate your input btw.