I think at the place you are with Houdini, USD and Solaris knowledge right now, the better way to go might be to spend a little bit more time following SideFX tutorials and Solaris FMX talks. Read the help documents for every node, very useful. Also check out the Pixars USD documents if you get the chance.
Your questions seems to repeat somewhat and have hopefully been answered, they also tend to be too broad and specific at the same time. For me they go beyond the scope of what can be explained in a forum post. Wish you the best of luck on your Solaris journey!
Found 61 posts.
Search results Show results as topic list.
Solaris and Karma » References, Payloads & Layers ?
- AndreasWeidman
- 127 posts
- Offline
Solaris and Karma » References, Payloads & Layers ?
- AndreasWeidman
- 127 posts
- Offline
Using SOP-create you would have it contained inside the solaris context, as an hda asset for instance. You could also have hydra pinned showing you the solaris viewport while working inside of it. Again, check pighead and grid for good use of it.
SOP-import I would personally never really use unless for legacy files. But whatever floats your boat
I have a heard time following what your asking here. Not sure why you would use scenen manager to load the file?
Sub-layers are mainly for combining changes from departments, where each department would have saved to a usd file with partial information. Layout.usd. Anim.us. FX.usd. Light.usd and so on to be combined into one. If you do not work like that, then you most likely want to use reference for all imports.
So for your last question. I don’t know what FX you want to do here. But one way without saving anything out would be:
- if you are working on an asset in a sopcreate. Primpath on sopcreate is set to say ”/myasset”
- In that SOPcreate you could add all the FX you want OR you could have a SOPmodify below it where you do the FX, making sure primpath is the same.
- Below those you could add a material library with shaders and textures pointing to that primpath.
If you rather save things out or are two people working, you can just write out each step to an usd file. And load them with reference and they will merge and inherit as long as the primpaths match.
So you could reference asset.usd, then FX.usd, When you have done your textures and updated asset.usd then those will be inherited.
Hope that makes sense.
SOP-import I would personally never really use unless for legacy files. But whatever floats your boat
I have a heard time following what your asking here. Not sure why you would use scenen manager to load the file?
Sub-layers are mainly for combining changes from departments, where each department would have saved to a usd file with partial information. Layout.usd. Anim.us. FX.usd. Light.usd and so on to be combined into one. If you do not work like that, then you most likely want to use reference for all imports.
So for your last question. I don’t know what FX you want to do here. But one way without saving anything out would be:
- if you are working on an asset in a sopcreate. Primpath on sopcreate is set to say ”/myasset”
- In that SOPcreate you could add all the FX you want OR you could have a SOPmodify below it where you do the FX, making sure primpath is the same.
- Below those you could add a material library with shaders and textures pointing to that primpath.
If you rather save things out or are two people working, you can just write out each step to an usd file. And load them with reference and they will merge and inherit as long as the primpaths match.
So you could reference asset.usd, then FX.usd, When you have done your textures and updated asset.usd then those will be inherited.
Hope that makes sense.
Solaris and Karma » References, Payloads & Layers ?
- AndreasWeidman
- 127 posts
- Offline
A lot of questions in this one. I'm probably not the right person to give you all the answers or the full depth of them, but here are a few basic things that may or may not help out
SOP-import:
will import things from within the same workfile from a SOPs network, not from disk. If you have done work in SOPs it can be handy for bringing it in to solaris, but I'd then rather use SOP-create to keep it all work inside of the solaris context.
SOP-create:
Will create an adhoc SOPs network disguised as a LOPs. Very useful for building things, lookdevs and other stuff (have a look at grid for example, or pighead).
SOP-modify:
Will also create an adhoc SOPs network, but also import whatever usd/lops content that was above it. Then you could blast stuff, model, do FX, UV map or whatever you want, and it will automatically be merged back as a replacement. OR, exported separately as a FX layer to be loaded back with reference (with primpath set to object changed, or new primpath), or if used with a layerbreak loaded with sublayer.
Reference:
Will import usd files or alembics etc from disk, and use the primpath to place them within the stage usd hierarchy. I.E. You might already have imported a lookdev with the primpath "/assets/foobar". If you later import the anim with a reference node and primpath also set to "/assets/foobar", it will merge them and inherit shading, uvs and other stuff.
Sublayer:
Will import usd-files from disk that already have "a place". For instance, in a proper usd workflow, only changes below a layerbreak would exported. Trying to reference that in would not work, since it is only partial information (the changes). So it needs to merge with other layers to work.
Example, if you have export a cube (/objects/cube) as cube.usd. Then (as an example) you also export that but with a layerbreak and a transform of the cube moving it as anim.usd. In a new file you now need to sublayer both cube.usd and anim.usd to see it working. anim.usd will not contain the cube itself.
Variants:
You create your geo however you want. Then add variants on new prim with path set to the top prim. (this prim cannot exist in stage at this point), from your geo, you can connect two assign material nodes, or edit materials to change disp or whatever you want. wire those to the variant node.
Then you should be able to right click on you instances and select variant, or create a setVariant node and add the instance number. Variants can be a bit tricky to understand for sure.
So to simplify, sublayers purpose is to combine the changes from different departments, while reference purpose is to bring in completely separate/standalone things. Reference has the same usecase as the nodes: volume, geometrysequence and value clip. I.E to bring in complete files.
As for payloads and settings for editable layer, instancable etc, It's all a blur for me still. I tend to leave it to the default.
SOP-import:
will import things from within the same workfile from a SOPs network, not from disk. If you have done work in SOPs it can be handy for bringing it in to solaris, but I'd then rather use SOP-create to keep it all work inside of the solaris context.
SOP-create:
Will create an adhoc SOPs network disguised as a LOPs. Very useful for building things, lookdevs and other stuff (have a look at grid for example, or pighead).
SOP-modify:
Will also create an adhoc SOPs network, but also import whatever usd/lops content that was above it. Then you could blast stuff, model, do FX, UV map or whatever you want, and it will automatically be merged back as a replacement. OR, exported separately as a FX layer to be loaded back with reference (with primpath set to object changed, or new primpath), or if used with a layerbreak loaded with sublayer.
Reference:
Will import usd files or alembics etc from disk, and use the primpath to place them within the stage usd hierarchy. I.E. You might already have imported a lookdev with the primpath "/assets/foobar". If you later import the anim with a reference node and primpath also set to "/assets/foobar", it will merge them and inherit shading, uvs and other stuff.
Sublayer:
Will import usd-files from disk that already have "a place". For instance, in a proper usd workflow, only changes below a layerbreak would exported. Trying to reference that in would not work, since it is only partial information (the changes). So it needs to merge with other layers to work.
Example, if you have export a cube (/objects/cube) as cube.usd. Then (as an example) you also export that but with a layerbreak and a transform of the cube moving it as anim.usd. In a new file you now need to sublayer both cube.usd and anim.usd to see it working. anim.usd will not contain the cube itself.
Variants:
You create your geo however you want. Then add variants on new prim with path set to the top prim. (this prim cannot exist in stage at this point), from your geo, you can connect two assign material nodes, or edit materials to change disp or whatever you want. wire those to the variant node.
Then you should be able to right click on you instances and select variant, or create a setVariant node and add the instance number. Variants can be a bit tricky to understand for sure.
So to simplify, sublayers purpose is to combine the changes from different departments, while reference purpose is to bring in completely separate/standalone things. Reference has the same usecase as the nodes: volume, geometrysequence and value clip. I.E to bring in complete files.
As for payloads and settings for editable layer, instancable etc, It's all a blur for me still. I tend to leave it to the default.
Solaris and Karma » Renderman Solaris UDIM tip
- AndreasWeidman
- 127 posts
- Offline
We've had this problem as well with Redshift. For some reason, the default token will be all jumbled with "%" and others things. Will render fine in hydra/viewport, but not at all in mplay/husk. Can't remember the the specific situation, could have been that the artist forgot to change the "type" in the drop down menu as well.
Edited by AndreasWeidman - July 24, 2021 15:35:49
Solaris and Karma » USD workflow Maya anim to Houdini
- AndreasWeidman
- 127 posts
- Offline
Too bad. That was what I was fearing, but expected expected, and the exact way of working we do currently.
It’s really a shame that this was Mayas USD implementation.
I suspect we’ll move our anim to Houdini and kinefx rigs before maya fixes this and gets onboard the usd train.
Glad to know I wasn’t crazy when trying to figure this thing out. Thanks for helping me confirm that Richard.
It’s really a shame that this was Mayas USD implementation.
I suspect we’ll move our anim to Houdini and kinefx rigs before maya fixes this and gets onboard the usd train.
Glad to know I wasn’t crazy when trying to figure this thing out. Thanks for helping me confirm that Richard.
Edited by AndreasWeidman - July 24, 2021 12:53:30
Solaris and Karma » USD workflow Maya anim to Houdini
- AndreasWeidman
- 127 posts
- Offline
Are you sure about that RichardFr? Because there seems to be no way at all to being in the model/sceneusd and rig as a stage and rig that. Mayas rigging tools, or any geo tool for that matter, cannot interact with usd elements in maya like it can with say sopmodify in houdini it seems.
You can import it/convert it into a regular maya content and export the anim as a seperate thing, (which is what we have been doing), but that, and only using the usd-files intead of alembics, has little to do with the proper usd workflow I am looking for. I.E only exporting the changes, the animation data etc, withing a strict manifest and inherits. Anything else would just be business as usual
What maya needs is SOP create, SOP modify, an SOP import functionality. Without that it does not seem that mayas usd stages would be uselful for anything really?
Appriciate the reply though!
You can import it/convert it into a regular maya content and export the anim as a seperate thing, (which is what we have been doing), but that, and only using the usd-files intead of alembics, has little to do with the proper usd workflow I am looking for. I.E only exporting the changes, the animation data etc, withing a strict manifest and inherits. Anything else would just be business as usual
What maya needs is SOP create, SOP modify, an SOP import functionality. Without that it does not seem that mayas usd stages would be uselful for anything really?
Appriciate the reply though!
Edited by AndreasWeidman - July 24, 2021 10:05:58
Solaris and Karma » USD workflow Maya anim to Houdini
- AndreasWeidman
- 127 posts
- Offline
USD. So what we do today is that we just reference that in. But that doesnt really jive with the optimal workflow we can use within houdini.
The optimal way would have been (simplified version):
- manifest.usd with the structure and all asset names.
- Some_model_asset.usd exported (name matching the manifest)
- These and other layers are linked in scene.usd
- Anim brings in scene.usd which automatically has the model. Rigs it. Animates it. Publish usd
- Light brings in scene.usd which now has the anim on the model (anim.usd + model.usd + manifest.usd).
But since maya doesnt seem to have a way of placeing things into a usd structure unless exporting it first, you would not be able to rig the model and keep it in the same structure. Or importing the model and placeing it in the structure even.
In other words. Maya seem only to be able to 1. import a usd structure and move/change things already there. But not add custom geo or anything to it. 2. Only way to export non-usd stuff to usd is to export the full non-usd stuff rather than just the changes/overrides that you actually want.
Drives me nuts. Just counting the days until we can go full on with kinefx
The optimal way would have been (simplified version):
- manifest.usd with the structure and all asset names.
- Some_model_asset.usd exported (name matching the manifest)
- These and other layers are linked in scene.usd
- Anim brings in scene.usd which automatically has the model. Rigs it. Animates it. Publish usd
- Light brings in scene.usd which now has the anim on the model (anim.usd + model.usd + manifest.usd).
But since maya doesnt seem to have a way of placeing things into a usd structure unless exporting it first, you would not be able to rig the model and keep it in the same structure. Or importing the model and placeing it in the structure even.
In other words. Maya seem only to be able to 1. import a usd structure and move/change things already there. But not add custom geo or anything to it. 2. Only way to export non-usd stuff to usd is to export the full non-usd stuff rather than just the changes/overrides that you actually want.
Drives me nuts. Just counting the days until we can go full on with kinefx
Solaris and Karma » USD workflow Maya anim to Houdini
- AndreasWeidman
- 127 posts
- Offline
We do our rigging and animation in maya, export that anim as a selfcontained usd file and reference into solaris.
Now, had we done the anim in houdini, we would be using a manifest and a layerbreak before the anim publish, and sublayering the anim into the correct place.
Since Maya is... well... maya. There doesnt seem to be any way to use a usd manifest file and output your anim as part of that structure. Or am I missing something?
Now, had we done the anim in houdini, we would be using a manifest and a layerbreak before the anim publish, and sublayering the anim into the correct place.
Since Maya is... well... maya. There doesnt seem to be any way to use a usd manifest file and output your anim as part of that structure. Or am I missing something?
Edited by AndreasWeidman - July 20, 2021 11:26:46
Solaris and Karma » Unpacking alembic in Solaris?
- AndreasWeidman
- 127 posts
- Offline
Not sure how you are getting this problem. But perhaps try and load it with a reference node instead. When set to "reference specific primitive" you could ctrl-click the arrow and browse the containing primitives.
Another option is to import it in a SOP-create node using the same node as in sops.
Another option is to import it in a SOP-create node using the same node as in sops.
Edited by AndreasWeidman - July 20, 2021 11:12:30
Solaris and Karma » LOPS Tutorial 4: Layerbreak doesn't show expected result
- AndreasWeidman
- 127 posts
- Offline
Not sure what tutorial you are working with or what state the example file is. Also don't know how your sublayer files are structured. But it looks right to me except for that merge node which would most likely merge everything above the layerbreak back in there causing the layerbreak to be useless probably.
Technical Discussion » Force cook a node when it is part of the tree viewed
- AndreasWeidman
- 127 posts
- Offline
I am trying to trigger a python node (should be the same as in SOPs) whenever that particular node is in the tree/branch currently viewed. Using "node.cook(force=True)" does work, but it gives me an error on the node with "Infinite recursion".
Basically, if I have two python nodes that prints the current time, I would like them to print the time whenever they or a node further down in each tree is selected.
Any idea on how to remove this error or another way to do it?
Basically, if I have two python nodes that prints the current time, I would like them to print the time whenever they or a node further down in each tree is selected.
Any idea on how to remove this error or another way to do it?
Technical Discussion » Set viewport BG image with python
- AndreasWeidman
- 127 posts
- Offline
I can't seem to figure out how to change the viewport background image with python.
https://www.sidefx.com/docs/houdini/hom/hou/GeometryViewportBackground.html [www.sidefx.com]
Seems like it should be pretty straight forward, but can't make it work. Can anyone share an example of how this class is used?
https://www.sidefx.com/docs/houdini/hom/hou/GeometryViewportBackground.html [www.sidefx.com]
Seems like it should be pretty straight forward, but can't make it work. Can anyone share an example of how this class is used?
Technical Discussion » STAGE: Set variant problems, editMaterial
- AndreasWeidman
- 127 posts
- Offline
mtucker
At a smaller studio, I think the only answer is education. With 16 artists, all of whom are expected to be able to create assets that take advantage of advanced USD features like variant sets, there is no substitute for making sure that everyone understands how this stuff works. So for such users, I see the job of SideFX being to provide lots and lots of high quality learning material, and examples, and starting points and templates that demonstrate best practices. And we are doing all these things, but they take time, and generally lag somewhat behind the development of the features in the software.
In terms of priorities, it is true that we have been so far focused on the large studios, because they can take advantage of the feature set without as much training material (because they can hire in-house expertise). But we have reached the point where we are starting to pivot to be more accessible to smaller studios (though of course all of this work also benefits the large studios, since easier to use software is easier for everyone to use, and they shouldn't need to provide as much custom tooling).
Agreed, training is vital. We have been enrolled with Houdini Insight for these purposes until it was taken down recently. And I myself try to contribute with doing talks for sidefx as well. For freelancers we would hope they learn this stuff on their own, much like Maya for instance.
I think solving the main thing holding Solaris back for smaller studios and independents, is just packaging somethings up, similar to the karma rendernode vs how you set up renderproduct & rendervars etc without it. Something like that is needed for variants as well. Simplified. Explore variants was a good start of that, and I hope we see more things like that in the future, and by your words, it seems like it may.
I guess the difference if sidefx does it vs every studio rolls their own hdas, is that all solaris artist will at least on some level have the same understanding of solaris, growing the number of artists and freelancers available for it.
Technical Discussion » STAGE: Set variant problems, editMaterial
- AndreasWeidman
- 127 posts
- Offline
mtucker
This kind of thing needs to be established long before it gets to the artist. If you plan your asset structure to enable this capability, then these operations can "just work" without the artist having to think about opinion strength at all.
In a setting where you have 1000 artists and 12 department it makes sense to handhold with custom setups for variants etc. For a smaller studio however, with 16 artist, we need our artists to be able to build whatever is needed for that project.
So it is a terrible shame if Solaris is only geared towards the big dogs with big tech departments, and not really meant to be used by regular artists like like they would with the rest of Houdini. It then becomes a hard sell to win over people from using blender, clarisse or maya, that can be used for lighting "out of the box" in a sense.
We love Solaris, but I do hope it will become more user friendly, so younglings playing with houdini at home, evolve into Solaris superstars instead of looking the other way.
Edited by AndreasWeidman - May 16, 2021 16:39:18
Solaris and Karma » Create variable to be picked up downstream? [SOLVED]
- AndreasWeidman
- 127 posts
- Offline
Turns out all I had to do was:
1 - Add a USD int to a node and set the value.
2 - Read it in with a python node: TheNodesPrimPath.GetAttribute("WhateverTheIntWasNamed").Get()
1 - Add a USD int to a node and set the value.
2 - Read it in with a python node: TheNodesPrimPath.GetAttribute("WhateverTheIntWasNamed").Get()
Solaris and Karma » Create variable to be picked up downstream? [SOLVED]
- AndreasWeidman
- 127 posts
- Offline
I'm trying something for sequence shots.
What I want to do is set a variable that can be picked up downstream but only in that branch.
So simplest imaginary version of it:
- Setting @scale=2 in an attribute wrangle (or something).
- Use @scale as expression/token for a cube/box's scale value.
- Being able to have multiple of these in their own branches, with their own values.
Maybe this is super obvious but cant get my head around it.
"Edit context option" only works upstream, so not an option. "store parameter values" does seem to do what i want either. Attribute wrangle does nothing. I also don't want to link to a particular node to set value.
What I want to do is set a variable that can be picked up downstream but only in that branch.
So simplest imaginary version of it:
- Setting @scale=2 in an attribute wrangle (or something).
- Use @scale as expression/token for a cube/box's scale value.
- Being able to have multiple of these in their own branches, with their own values.
Maybe this is super obvious but cant get my head around it.
"Edit context option" only works upstream, so not an option. "store parameter values" does seem to do what i want either. Attribute wrangle does nothing. I also don't want to link to a particular node to set value.
Edited by AndreasWeidman - May 16, 2021 16:00:43
Technical Discussion » STAGE: Set variant problems, editMaterial
- AndreasWeidman
- 127 posts
- Offline
mtucker
You have to make sure that the prim on which you are authoring the variants has all its opinions (or at least all opinions affected by the variants) defined through a reference. This can be a reference to another prim in the scene graph rather than a reference to a separate file on disk. So suppose you have /mats/material1 on which you want to create variants. Instead of creating the variants on /mats/material1, you would deactivate /mats/material1, and create /mats/material1_with_variants that is a reference to /mats/material1. Then define your variants on /mats/material1_with_variants.
Of course doing this dance requires that you to your material assignment after authoring the variants (or updating the assignments after the fact). As is often the case with USD, planning your sceen structure ahead of time is key to exploiting its flexibility.
This seems like a flawed approach. We could never expect artists to do this dance in production. Things suddenly changing names due to a new set of variants somewhere. It is also not intuitive at all.
Variants was one of the biggest selling points of Solaris, and I wish is just behaved like if I merged each "variant" on with a switch, which is what we are doing instead. No opinion problems there. Perhaps if there was a node to actually set the opinion strength of a branch like configure layer/primitive or something, that would be nice.
Solaris and Karma » timeshift or retimeinstances on selected/named item
- AndreasWeidman
- 127 posts
- Offline
I never solved this, but for now I made variants with different speedshifts and then sets variant on any instance I like. Would still love to do it the other way
Solaris and Karma » timeshift or retimeinstances on selected/named item
- AndreasWeidman
- 127 posts
- Offline
Have been trying to offset the animation of an instance/copy. When searching this forum and downloading example hip files, they all seem to use array based selection, "instance" or similar.
However, for my use case, I'd like to manually select my "instanceable reference" or "reference" in the selector list (or viewport) getting: "/copytopints/Instance0"; but when doing so I get no results with retimeinstances. And when using timeshift, all instances time shifts, not only the selected one.
Basically, just like with a transform set to "/copytopints/Instance0" I could move that instance. So I'm confused why that would not work as selection with timeshift as well?
Slowly, slowly grasping my thick head around Solaris. Appreciate the guidance.
However, for my use case, I'd like to manually select my "instanceable reference" or "reference" in the selector list (or viewport) getting: "/copytopints/Instance0"; but when doing so I get no results with retimeinstances. And when using timeshift, all instances time shifts, not only the selected one.
Basically, just like with a transform set to "/copytopints/Instance0" I could move that instance. So I'm confused why that would not work as selection with timeshift as well?
Slowly, slowly grasping my thick head around Solaris. Appreciate the guidance.
Edited by AndreasWeidman - March 4, 2021 17:26:26
Solaris and Karma » Solaris viewport subdivision bug?
- AndreasWeidman
- 127 posts
- Offline
-
- Quick Links