Hi everyone, learning SOLARIS here.
i do a lot of automobile-related visualization work.
before testing SOLARIS, i would usually have a GEO node with most of my mesh prepared.
so i would have the wheels, chassis, engine prepared here.
and when i need to rig them or animated them, i would create a new SUBNET on /OBJ level, and inside it have a NULL and use them as a rigging structure. so i would have main NULL, which connects to BODY, WHEELS ENGINE etc, and the NULLs are animated. (this way i can separate the animation from the mesh date, so eash to manage projects)
but basically any kind of simple rig with combination or parenting, some expression, and some keyframes.
however, i am trying to understand what the proper workflow is for USD to do something like this.
it feels like SOLARIS/USD workflow is to prepare MESH assets in /OBJ level, but do a placement, materials on /STATE USD context?
if placement happens on USD/SOLARIS context, shouldn't animation happen here as well? but feels like USD is not built as an animation/rigging tool, but rather a "staging tool"
if this is the case, should i be doing all the assembly, placement, animation in /OBJ level and bring in the whole animated mesh into SOLARIS/USD?
thank you in advance!
RIGGING, ANIMATION WORKFLOW with SOLARIS?
3961 3 0- alteredgene
- Member
- 19 posts
- Joined: March 2020
- Offline
- jsmack
- Member
- 7758 posts
- Joined: Sept. 2011
- Online
alteredgene
if this is the case, should i be doing all the assembly, placement, animation in /OBJ level and bring in the whole animated mesh into SOLARIS/USD?
That way makes the most sense to me. The scene import node can import an object hierarchy from /obj intact.
Solaris isn't really meant to do rigging/animation, although with its constraints and transform hierarchies it could be technically used for some simple kinds of animation.
- alteredgene
- Member
- 19 posts
- Joined: March 2020
- Offline
Thank you for your response jsmack!
yep that's the sense i got, USD used as a final "assembly" pipeline tool.
but due to USD being "universal", feels like there is quite a bit of workaround of USD specific approach that's required to get it working with normal (at least how i use HOUDINI) workflow.
i love the concept of USD, and definitely can see a huge benefit for a larger team, but right now, again as a SOLO artist, feels compromises are greater than the benefit.
that being said, i have been trying to immigrate my existing project into USD, so i can get a real-world project experience with it.
but think USD is something i need to commit from the start and set up the workflow around it, rather than using it as an extra tool here and there.
yep that's the sense i got, USD used as a final "assembly" pipeline tool.
but due to USD being "universal", feels like there is quite a bit of workaround of USD specific approach that's required to get it working with normal (at least how i use HOUDINI) workflow.
i love the concept of USD, and definitely can see a huge benefit for a larger team, but right now, again as a SOLO artist, feels compromises are greater than the benefit.
that being said, i have been trying to immigrate my existing project into USD, so i can get a real-world project experience with it.
but think USD is something i need to commit from the start and set up the workflow around it, rather than using it as an extra tool here and there.
- jsmack
- Member
- 7758 posts
- Joined: Sept. 2011
- Online
I think even if you do everything outside of solaris, and don't use USD in the pipeline, using it as a glorified ROP has its benefits. It makes experimenting with lighting/render settings a lot more like experimenting in sops. Stuff that would be a pain to do with the old mantra ROP's candidate parameters becomes fluid.
-
- Quick Links