You can access the usd_attrib(utes) and usd_localtransform(s) from a wrangle node in sops. Just make sure that there's a file node inbetween this query and the export to lops. Otherwise there's a problem (infinite loop).
No need for a lop camera import if this is possible.
Found 143 posts.
Search results Show results as topic list.
Solaris and Karma » Extract Solaris Camera Position to SOP Geometry
-
- Tom Mangold
- 143 posts
- Offline
Technical Discussion » Mtlx AO backface issue
-
- Tom Mangold
- 143 posts
- Offline
This seems to me like a bug. Backfaces appear black and not shaded correctly.
As if the normal for the ao calculation is pointing in the normal of the prim, but the shading is transfered to it's back. As if doubled sided calculations are broken.
Can anybody confirm this?
Using a mesh edit node with double sided checked didn't change anything.
Cheers
Tom
As if the normal for the ao calculation is pointing in the normal of the prim, but the shading is transfered to it's back. As if doubled sided calculations are broken.
Can anybody confirm this?
Using a mesh edit node with double sided checked didn't change anything.
Cheers
Tom
Solaris and Karma » Rendervisibility -reflect NOT excluding coat reflections
-
- Tom Mangold
- 143 posts
- Offline
primvars::karma::object::rendervisibility -> -reflect not excluding the coat reflections. Is there a special flag like -coat (which doesn't work)?
Consider this kind of a bug.
Is there a list with additional flags except from the ones which pop up by using the presets?
Cheers
Tom
Consider this kind of a bug.
Is there a list with additional flags except from the ones which pop up by using the presets?
Cheers
Tom
Technical Discussion » No lights but the scene is not black
-
- Tom Mangold
- 143 posts
- Offline
This is unfortunately not feature, but something which just costs time. Especially since 20.5 it can only be disabled in the USD Render ROP.
No way to check the emission on it's own in the viewport. One needs to create a point light and place it infinity so that it won't light anything.
It's utterly strange to force a front light onto the user. If all lights are disabled, it's for a reason. If a headlight is needed, easy to create one.
At least bring it back into the Karma render settings, so that the scene can be viewed without the headlight. Or introduce it as a global preference setting.
No way to check the emission on it's own in the viewport. One needs to create a point light and place it infinity so that it won't light anything.
It's utterly strange to force a front light onto the user. If all lights are disabled, it's for a reason. If a headlight is needed, easy to create one.
At least bring it back into the Karma render settings, so that the scene can be viewed without the headlight. Or introduce it as a global preference setting.
Solaris and Karma » Proxy mesh workflow
-
- Tom Mangold
- 143 posts
- Offline
I highly appreciate your help!
Will still have to check the files though.
I made some progress in the meantime and I guess it's been your advice to "import as references" which made the difference. Suddenly it works. The python code with "AddReference()" does the job, "overwriting" the current low res mesh with the link to the high res one. Will post my code/scene later on so that hopefully somebody can profit from it too or tell me that this is the utterly wrong way to do it! : )
Will still have to check the files though.
I made some progress in the meantime and I guess it's been your advice to "import as references" which made the difference. Suddenly it works. The python code with "AddReference()" does the job, "overwriting" the current low res mesh with the link to the high res one. Will post my code/scene later on so that hopefully somebody can profit from it too or tell me that this is the utterly wrong way to do it! : )
Solaris and Karma » Proxy mesh workflow
-
- Tom Mangold
- 143 posts
- Offline
P.S.: Can my problem be that I'm trying to sublayer a mesh which is probably not a layer in terms of the USD definitions? I also recreated the stage with an inline sop loading the .usd high res files. Just without the proxy meshes.
/
____/parking_lot (xform)
________/cars (xform)
____________/car_a (mesh) -> high res mesh, purpose "render"
____________/car_b (mesh) -> high res mesh, purpose "render"
____________/...
Using a sublayer node with the stage tree as seen in my former post in the 1st input and this tree in the second input also does nothing, EXCEPT from coloring the "cars" xform" green.
I though it would override the car_a and additional cars as well. : (
/
____/parking_lot (xform)
________/cars (xform)
____________/car_a (mesh) -> high res mesh, purpose "render"
____________/car_b (mesh) -> high res mesh, purpose "render"
____________/...
Using a sublayer node with the stage tree as seen in my former post in the 1st input and this tree in the second input also does nothing, EXCEPT from coloring the "cars" xform" green.
I though it would override the car_a and additional cars as well. : (
Solaris and Karma » Proxy mesh workflow
-
- Tom Mangold
- 143 posts
- Offline
Thanks so much! Again! : )
The only thing which stays unresolved yet is that my sublayer mesh doesn't replace the imported sop mesh. I thought by adding a sublayer Houdini/USD would check for another layer with the same name and replace it.
My stage looks a bit like this:
/
____/parking_lot (xform)
________/cars (xform)
____________/car_a__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_a (mesh) -> low res mesh, purpose "render"
____________/car_b__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_b (mesh) -> low res mesh, purpose "render"
____________/car_c__proxy (mesh) -> low res mesh, purpose "proxy"
____________/...
This got created by using a sopimport LOP node with import path prefix set to "/parking lot/cars". The meshes do carry the name attributes "car_a" and so on.
Now I use the sublayer LOP and import the high res mesh with the name attribute "car_a". Or the python code you posted. Same result.
I thought that it would replace my low poly mesh since it got the same name attribute. But it doesn't. It just adds it to the stage.
/
____/Geometry
________/car_a
____/parking_lot (xform)
________/cars (xform)
____________/car_a__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_a (mesh) -> low res mesh, purpose "render"
____________/car_b__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_b (mesh) -> low res mesh, purpose "render"
____________/car_c__proxy (mesh) -> low res mesh, purpose "proxy"
____________/...
BUT if I save the high res mesh with the name "/parking_lot/cars/car_a" it replaces the low res car like desired.
The problem is that I might want to place "car_a" in another scene not in a parking lot between other cars, but in a landscape.
/
____/landscape
________/car_a
So saving my high res asset with an absolute path is obviously not the best choice, since the car doesn't really now yet where it's going to be placed.
What I expect the tree to look like is
/
____/parking_lot (xform)
________/cars (xform)
____________/car_a__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_a (mesh) -> high res mesh, purpose "render"
____________/car_b__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_b (mesh) -> high res mesh, purpose "render"
____________/car_c__proxy (mesh) -> low res mesh, purpose "proxy"
____________/...
An alternative would be to already pass on an ".usd" path to the low res prims as a reference, but this seems to be not possible as far as I can tell.
Sorry for the underscores, but the spaces were removed.
The only thing which stays unresolved yet is that my sublayer mesh doesn't replace the imported sop mesh. I thought by adding a sublayer Houdini/USD would check for another layer with the same name and replace it.
My stage looks a bit like this:
/
____/parking_lot (xform)
________/cars (xform)
____________/car_a__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_a (mesh) -> low res mesh, purpose "render"
____________/car_b__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_b (mesh) -> low res mesh, purpose "render"
____________/car_c__proxy (mesh) -> low res mesh, purpose "proxy"
____________/...
This got created by using a sopimport LOP node with import path prefix set to "/parking lot/cars". The meshes do carry the name attributes "car_a" and so on.
Now I use the sublayer LOP and import the high res mesh with the name attribute "car_a". Or the python code you posted. Same result.
I thought that it would replace my low poly mesh since it got the same name attribute. But it doesn't. It just adds it to the stage.
/
____/Geometry
________/car_a
____/parking_lot (xform)
________/cars (xform)
____________/car_a__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_a (mesh) -> low res mesh, purpose "render"
____________/car_b__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_b (mesh) -> low res mesh, purpose "render"
____________/car_c__proxy (mesh) -> low res mesh, purpose "proxy"
____________/...
BUT if I save the high res mesh with the name "/parking_lot/cars/car_a" it replaces the low res car like desired.
The problem is that I might want to place "car_a" in another scene not in a parking lot between other cars, but in a landscape.
/
____/landscape
________/car_a
So saving my high res asset with an absolute path is obviously not the best choice, since the car doesn't really now yet where it's going to be placed.
What I expect the tree to look like is
/
____/parking_lot (xform)
________/cars (xform)
____________/car_a__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_a (mesh) -> high res mesh, purpose "render"
____________/car_b__proxy (mesh) -> low res mesh, purpose "proxy"
____________/car_b (mesh) -> high res mesh, purpose "render"
____________/car_c__proxy (mesh) -> low res mesh, purpose "proxy"
____________/...
An alternative would be to already pass on an ".usd" path to the low res prims as a reference, but this seems to be not possible as far as I can tell.
Sorry for the underscores, but the spaces were removed.
Edited by Tom Mangold - Nov. 13, 2024 10:27:46
Solaris and Karma » Proxy mesh workflow
-
- Tom Mangold
- 143 posts
- Offline
Thanks so much for your example!
My workflow is slightly different and my problem unfortunately remains. : )
In the folder with my high res geo are about 20.000files, all .usd with a name attribute.
In SOPs I do have several low res primitives which then get transfered to LOPs.
These low res prims do carry a name and a path attribute. Name is identical to the high res version, path attribute is the path to the high res version.
In order to to see the low res prims there are two prims for each of them. One with the purpose "proxy" and "_proxy" attached to its name and one with "render" as the purpose.
If I use Houdini's sublayer LOP node and manually choose one of the high res files which is present on the stage as a low res file, then it replaces the low res "render" prim.
Everything as I'd like it to be. It displays the low res prim and renders the high res prim. BINGO.
Since I can't do this manually for all the prims I want to sublayer these files in the python lop.
https://docs.omniverse.nvidia.com/dev-guide/latest/programmer_ref/usd/layers/add-sublayer.html [docs.omniverse.nvidia.com]
That's the only help I can find on this subject. Unfortunately the code doesn't work. It throws an error "A layer already exists with identifier". Guess that's the fault of the CreateNew()
It's really tricky to find ANY documentation on python and sublayers except this one. And the usual search commands will almost always point you to this page. : /
https://docs.omniverse.nvidia.com/dev-guide/latest/programmer_ref/usd/references-payloads/add-reference.html [docs.omniverse.nvidia.com]
I wished I could see the python code within the sublayer LOP (knowing that it's most likely not python based).
I managed to get hold of all the low res prims I need to exchange and also the path attribute in python. I just struggle with the python code to override the layer with the sublayer or add the sublayer with the higher opinion (whatever the right terminology might be).
Anybody who knows the right syntax?
P.S.: I also exchanged stage with stage = node.editableStage() in the following code, still throws the error.
from pxr import Sdf
def add_sub_layer(sub_layer_path: str, root_layer) -> Sdf.Layer:
sub_layer: Sdf.Layer = Sdf.Layer.CreateNew(sub_layer_path)
# You can use standard python list.insert to add the subLayer to any position in the list
root_layer.subLayerPaths.append(sub_layer.identifier)
return sub_layer
#############
# Full Usage
#############
from pxr import Usd
# Get the root layer
stage: Usd.Stage = Usd.Stage.CreateInMemory()
root_layer: Sdf.Layer = stage.GetRootLayer()
# Add the sub layer to the root layer
sub_layer = add_sub_layer(r"C:/path/to/sublayer.usd", root_layer)
usda = stage.GetRootLayer().ExportToString()
print(usda)
# Check to see if the sublayer is loaded
loaded_layers = root_layer.GetLoadedLayers()
assert sub_layer in loaded_layers
My workflow is slightly different and my problem unfortunately remains. : )
In the folder with my high res geo are about 20.000files, all .usd with a name attribute.
In SOPs I do have several low res primitives which then get transfered to LOPs.
These low res prims do carry a name and a path attribute. Name is identical to the high res version, path attribute is the path to the high res version.
In order to to see the low res prims there are two prims for each of them. One with the purpose "proxy" and "_proxy" attached to its name and one with "render" as the purpose.
If I use Houdini's sublayer LOP node and manually choose one of the high res files which is present on the stage as a low res file, then it replaces the low res "render" prim.
Everything as I'd like it to be. It displays the low res prim and renders the high res prim. BINGO.
Since I can't do this manually for all the prims I want to sublayer these files in the python lop.
https://docs.omniverse.nvidia.com/dev-guide/latest/programmer_ref/usd/layers/add-sublayer.html [docs.omniverse.nvidia.com]
That's the only help I can find on this subject. Unfortunately the code doesn't work. It throws an error "A layer already exists with identifier". Guess that's the fault of the CreateNew()
It's really tricky to find ANY documentation on python and sublayers except this one. And the usual search commands will almost always point you to this page. : /
https://docs.omniverse.nvidia.com/dev-guide/latest/programmer_ref/usd/references-payloads/add-reference.html [docs.omniverse.nvidia.com]
I wished I could see the python code within the sublayer LOP (knowing that it's most likely not python based).
I managed to get hold of all the low res prims I need to exchange and also the path attribute in python. I just struggle with the python code to override the layer with the sublayer or add the sublayer with the higher opinion (whatever the right terminology might be).
Anybody who knows the right syntax?
P.S.: I also exchanged stage with stage = node.editableStage() in the following code, still throws the error.
from pxr import Sdf
def add_sub_layer(sub_layer_path: str, root_layer) -> Sdf.Layer:
sub_layer: Sdf.Layer = Sdf.Layer.CreateNew(sub_layer_path)
# You can use standard python list.insert to add the subLayer to any position in the list
root_layer.subLayerPaths.append(sub_layer.identifier)
return sub_layer
#############
# Full Usage
#############
from pxr import Usd
# Get the root layer
stage: Usd.Stage = Usd.Stage.CreateInMemory()
root_layer: Sdf.Layer = stage.GetRootLayer()
# Add the sub layer to the root layer
sub_layer = add_sub_layer(r"C:/path/to/sublayer.usd", root_layer)
usda = stage.GetRootLayer().ExportToString()
print(usda)
# Check to see if the sublayer is loaded
loaded_layers = root_layer.GetLoadedLayers()
assert sub_layer in loaded_layers
Edited by Tom Mangold - Nov. 12, 2024 14:10:42
Solaris and Karma » Proxy mesh workflow
-
- Tom Mangold
- 143 posts
- Offline
Thanks so much for your input, which is really helpful to get the general idea.
But from a practical standpoint, how would I approach this?
I'd import the low res versions of the files (really low res on memory) into lops, reduce them in a sop modify node with a custom node depending on the camera view (delete prims which are out of view), pack them to get a point attribute with the USD reference file name, and then? At this point I'd like to establish that Houdini uses the file path to load the geo for rendering purposes while displaying the proxy version packed one).
How do I use the file path info to make it a reference. I'd like to choose a wrangle and convert it to a reference. Is this the way to go? The amount of different meshes requires that I use the file path attribute. I can't set up anything by hand per object.
Cheers
Tom
But from a practical standpoint, how would I approach this?
I'd import the low res versions of the files (really low res on memory) into lops, reduce them in a sop modify node with a custom node depending on the camera view (delete prims which are out of view), pack them to get a point attribute with the USD reference file name, and then? At this point I'd like to establish that Houdini uses the file path to load the geo for rendering purposes while displaying the proxy version packed one).
How do I use the file path info to make it a reference. I'd like to choose a wrangle and convert it to a reference. Is this the way to go? The amount of different meshes requires that I use the file path attribute. I can't set up anything by hand per object.
Cheers
Tom
Solaris and Karma » Swap proxies with high res meshes from disk in Karma
-
- Tom Mangold
- 143 posts
- Offline
Imagine a car park with hundreds of different unique vehicles, each 1.000.000 polys+. Impossible to load that scene into memory or even work with it.
Only way I see is to use proxies with a very limited amount of prims and have a file path which loads the geo if needed during the render takes place.
The purpose attribute with render/proxy seems to be kind of the way to do it, but the geo can't be kept in the scene memory. This would be a jut a solution to speed up opengl work, but doesn't overcome any limits set by the physical memory in the pc.
So, how is this practically done? With instances, with a special attribute, or something else?
Would love to get some input on this.
Cheers
Tom
Only way I see is to use proxies with a very limited amount of prims and have a file path which loads the geo if needed during the render takes place.
The purpose attribute with render/proxy seems to be kind of the way to do it, but the geo can't be kept in the scene memory. This would be a jut a solution to speed up opengl work, but doesn't overcome any limits set by the physical memory in the pc.
So, how is this practically done? With instances, with a special attribute, or something else?
Would love to get some input on this.
Cheers
Tom
Solaris and Karma » Proxy mesh workflow
-
- Tom Mangold
- 143 posts
- Offline
This topic covers the render and proxy settings for geo which can be hold in Houdini'S memory. What about if the proxy doesn't have a render equivalent in the scene, but a file path to a .bgeo or .usd file on disk. How is this handled? Especially if we are talking about hundreds of different high res meshes.
Solaris and Karma » Motion vector AOV in Karma
-
- Tom Mangold
- 143 posts
- Offline
Might have found the solution. IF I create a custom motion vector path "Disable image blur2 is grayed out and I get amotion vector and beauty image with MB applied.
If I just use the one click motion vector path the dialogue "Disable image blur" goes live and you can click it.
If I just use the one click motion vector path the dialogue "Disable image blur" goes live and you can click it.
Solaris and Karma » Motion vector AOV in Karma
-
- Tom Mangold
- 143 posts
- Offline
Thanks so much! Putting in the node finally gives me MB and the vectors. But I can't get rid of Karma actually motion blurring the image. While "Disable image blur" is on, it's also grayed out. So, I only need the vectors. : /
Need to check your file tomorrow.
Need to check your file tomorrow.
Solaris and Karma » Motion vector AOV in Karma
-
- Tom Mangold
- 143 posts
- Offline
20.5 the same. No shading except from black pixels in the motion vectors aov. 20.5.332
Normal map, depth map, all show up nicely. MV doesn't.
What are the setting which need to be enabled/disabled to get the correct aov?
Normal map, depth map, all show up nicely. MV doesn't.
What are the setting which need to be enabled/disabled to get the correct aov?
Solaris and Karma » Motion vector AOV in Karma
-
- Tom Mangold
- 143 posts
- Offline
Simply doesn't work in 20. Nightmare. Or 20 settings need to be in a certain way that even a lottery win is more likely. Both CPU and XPU don't tint any pixel in the Motion Vector path.
Technical Discussion » Solaris workflow questions
-
- Tom Mangold
- 143 posts
- Offline
As much as I like aspects of the USD environment, there are currently more which I consider a handicap.
While some problems can be solved with some workarounds, others still remain a mystery.
a) How do I mimic the @instancefile workflow from sops? Right now I need to create a "sop create" node with a file import node inside to import a lot of files for instancing. One sop for each file, using the sop name as the file ending to "automatically" fill out the file name for import. How do I use an attribute, e.g. on the instance points to load a file or import a whole directory of prims for instancing? That's one of the strength of Houdini in general. But in USD?
b) Once the instances are spawned I need to edit some them some of for still life images because of the art direction. The tree or skyscraper needs to be moved or deleted. In SOP context no problem. Edit sop and I move or delete the point holding the packed geo. In USD it seems that I can't edit nor select the prim spawned on the point. I need to go back into the pointcloud, try to figure out which point is responsible for the instance and edit or delete the point. In SOP context I can easily use the instanced geo to select the point, in USD nothing happens. The selection tool doesn't select anything.
c) What makes it even more difficult to alter instances is that I can't keep the camera view from solaris switching into the sop context. Sop will have it's own viewport, lop camera not available as a choice for the perspective. Really difficult for selections or model/move something in camera space. Only workaround: Create a sop camera with the same settings and switch from stage to obj mode. Absolute workflow killer.
d) Searched a lot, but found no official way to do this: How to import a material name that it turns into a material binding on lop import and NOT a primvar? I don't want to import an existing material, but want to link the primitives with an attribute to an existing material in lops.
There's a vex script which does this which is at the same time not recommended.
While learning new stuff is also a joy, loosing methods which work perfectly fine is not helping to solve the daily tasks.
I'd highly appreciate some tips to make working with Solaris and Karma more user friendly.
Cheers
Tom
While some problems can be solved with some workarounds, others still remain a mystery.
a) How do I mimic the @instancefile workflow from sops? Right now I need to create a "sop create" node with a file import node inside to import a lot of files for instancing. One sop for each file, using the sop name as the file ending to "automatically" fill out the file name for import. How do I use an attribute, e.g. on the instance points to load a file or import a whole directory of prims for instancing? That's one of the strength of Houdini in general. But in USD?
b) Once the instances are spawned I need to edit some them some of for still life images because of the art direction. The tree or skyscraper needs to be moved or deleted. In SOP context no problem. Edit sop and I move or delete the point holding the packed geo. In USD it seems that I can't edit nor select the prim spawned on the point. I need to go back into the pointcloud, try to figure out which point is responsible for the instance and edit or delete the point. In SOP context I can easily use the instanced geo to select the point, in USD nothing happens. The selection tool doesn't select anything.
c) What makes it even more difficult to alter instances is that I can't keep the camera view from solaris switching into the sop context. Sop will have it's own viewport, lop camera not available as a choice for the perspective. Really difficult for selections or model/move something in camera space. Only workaround: Create a sop camera with the same settings and switch from stage to obj mode. Absolute workflow killer.
d) Searched a lot, but found no official way to do this: How to import a material name that it turns into a material binding on lop import and NOT a primvar? I don't want to import an existing material, but want to link the primitives with an attribute to an existing material in lops.
There's a vex script which does this which is at the same time not recommended.
While learning new stuff is also a joy, loosing methods which work perfectly fine is not helping to solve the daily tasks.
I'd highly appreciate some tips to make working with Solaris and Karma more user friendly.
Cheers
Tom
Technical Discussion » Instancing packed geometry in Karma
-
- Tom Mangold
- 143 posts
- Offline
So far I just achieve results in which the transforms of the packed twigs are all messed up and over the place.
Is this even possible? Instancing geo with packed geo on top of it?
Is this even possible? Instancing geo with packed geo on top of it?
Technical Discussion » Instancing packed geometry in Karma
-
- Tom Mangold
- 143 posts
- Offline
Nobody???
Should I pack the whole tree (unique branches + packed twigs and leaves) together? Do I need to save it as an .usd file or will a sop import do the trick? Which settings are recommended on the instancer node?
Would appreciate if somebody could share a hint.
Cheers
Tom
P.S.: Instancing unpacked geo doesn't seem to be a problem. Maybe it's much lighter than the tree I'm trying to instance (unpacked 100.000.000 polys).
Should I pack the whole tree (unique branches + packed twigs and leaves) together? Do I need to save it as an .usd file or will a sop import do the trick? Which settings are recommended on the instancer node?
Would appreciate if somebody could share a hint.
Cheers
Tom
P.S.: Instancing unpacked geo doesn't seem to be a problem. Maybe it's much lighter than the tree I'm trying to instance (unpacked 100.000.000 polys).
Technical Discussion » Instancing packed geometry in Karma
-
- Tom Mangold
- 143 posts
- Offline
What's the secret? If I import my tree – branches unique geo, twigs with leaves packed geo – it displays correctly. If I instance this prim the branches and twigs are separated and I can see only the instanced twigs once, not "attached" to the branches.
How is this done correctly? Also how would nested packed geo work? Like packed leaves on packed twigs?
Cheers
Tom
How is this done correctly? Also how would nested packed geo work? Like packed leaves on packed twigs?
Cheers
Tom
Technical Discussion » Boosting secondary rays in Karma
-
- Tom Mangold
- 143 posts
- Offline
Is this possible? In /obj lights we have "contributions" which can be set to "indirect", Karma lights in the /stage don't have the indirect feature.
Is this hidden in some "settings" node or do I need to comp this with an "diffuse_indirect" pass?
Cheers
Tom
Is this hidden in some "settings" node or do I need to comp this with an "diffuse_indirect" pass?
Cheers
Tom
-
- Quick Links