Found 15 posts.
Search results Show results as topic list.
Technical Discussion » Feature: Allow Variables and Channels in node names
- Belal
- 15 posts
- Offline
It would be great if we can set the name of a node with global variables and channels especially in Solaris.
Solaris and Karma » Feature request: usd_rop "Flatten Stage (Preserve all sublayers and references)"
- Belal
- 15 posts
- Offline
Thanks for information, I see what you mean.
I believe that yes as you also mentioned, resolving and building all of it in the usd_rop itself would help, my aim was to be able to get a one clean scene description file that at least doesn't flatten the binary data from the incoming referenced usds/alembics into the new file for any reason but to keep them references to their original files on disk.
I believe that yes as you also mentioned, resolving and building all of it in the usd_rop itself would help, my aim was to be able to get a one clean scene description file that at least doesn't flatten the binary data from the incoming referenced usds/alembics into the new file for any reason but to keep them references to their original files on disk.
Solaris and Karma » Feature request: usd_rop "Flatten Stage (Preserve all sublayers and references)"
- Belal
- 15 posts
- Offline
The usd_rop to have an additional "Save Style" called "Flatten Stage (Preserve all sublayers and references)" that flattens any node that isn't a sublayer or file reference inside the same saved USD stage file that has everything else referenced as sublayer or payload.
The current behavior:
Houdini is generating intermediate USDs that were never requested and references them in the final generated stage (this behavior is not recommended especially from a pipeline point of view), we have to have control on what files is getting generated and we have to be able to name them and decide where they will be saved before they do (and most importantly to have track of them - as with this current behavior, you don't know what are the intermediate files that will written out during the usd_rop evaluation).
The desired behavior:
usd_rop should have the ability to write just one USD stage, that has all references and sublayers written as references (not flattened), while every other user nodes like graft, transform... etc., should be flattened in the same USD stage file (rather than being written to external intermediate usd files).
The current behavior:
Houdini is generating intermediate USDs that were never requested and references them in the final generated stage (this behavior is not recommended especially from a pipeline point of view), we have to have control on what files is getting generated and we have to be able to name them and decide where they will be saved before they do (and most importantly to have track of them - as with this current behavior, you don't know what are the intermediate files that will written out during the usd_rop evaluation).
The desired behavior:
usd_rop should have the ability to write just one USD stage, that has all references and sublayers written as references (not flattened), while every other user nodes like graft, transform... etc., should be flattened in the same USD stage file (rather than being written to external intermediate usd files).
Edited by Belal - Oct. 20, 2021 14:09:42
Technical Discussion » Solaris: Material Assign with CVEX and prim userProperties
- Belal
- 15 posts
- Offline
Thanks Tamte for sharing...
What I meant is the option of assigning the material based on pattern using 'mat' usd properties (in usd this is userProperties:mat).
the file you shared works awesome as long as the property 'mat' is there since you created it houdini, but it doesn't when mat is on a usd primvitive because houdini didn't import it! it could be that there is something we have to do to tell Houdini that we want to import the userProperties.
There two issues actually:
1. Houdini didn't import the userProperties:* found in the usd (even when requested this in the Import data fields of SOP import)
2. Houdini imported the primvars only (where in this case, s@mat == "skin" didn't work because the 'mat' primvar will be in form of array of string not string (in the usd, mat is not "skin"), trying something like s@mat == "skin" didn't work either
What I meant is the option of assigning the material based on pattern using 'mat' usd properties (in usd this is userProperties:mat).
the file you shared works awesome as long as the property 'mat' is there since you created it houdini, but it doesn't when mat is on a usd primvitive because houdini didn't import it! it could be that there is something we have to do to tell Houdini that we want to import the userProperties.
There two issues actually:
1. Houdini didn't import the userProperties:* found in the usd (even when requested this in the Import data fields of SOP import)
2. Houdini imported the primvars only (where in this case, s@mat == "skin" didn't work because the 'mat' primvar will be in form of array of string not string (in the usd, mat is not "skin"), trying something like s@mat == "skin" didn't work either
Edited by Belal - Oct. 6, 2021 04:18:21
Technical Discussion » Solaris: Resolve texture paths based on primitive attributes
- Belal
- 15 posts
- Offline
You created the attribute in houdini, did you try if this attribute is on a primitive in a usd file? (this what didn't work at my end, if primitive box is from a usd referenced file, and this box has a primvars:whatEver this primvar works as long as it's not string, if it's set to string, then it didn't work), on the other hand, only primvars: works, having userProperties:whatEver doesn't work as they are not imported even when I tried to load them in the import data files in SOP Import).
Technical Discussion » Solaris: Resolve texture paths based on primitive attributes
- Belal
- 15 posts
- Offline
Thanks Andy for sharing this... this worked color primvars, but didn't work string primvars, as well as that it didn't work with userProperties
your implementation is the right way, but it seems that Houdini itself didn't import the desired attributes (or at least not importing string attributes).
Development team input on this will be appreciated
your implementation is the right way, but it seems that Houdini itself didn't import the desired attributes (or at least not importing string attributes).
Development team input on this will be appreciated
Technical Discussion » Solaris: Material Assign with CVEX and prim userProperties
- Belal
- 15 posts
- Offline
Thanks for your reply Tamte, but the point here is to see if we can access the USD primvars and userProperties through the shading interface in an attempt to maintain our pipeline methodology where we have lots of advantages based on this method.
Technical Discussion » Solaris: Resolve texture paths based on primitive attributes
- Belal
- 15 posts
- Offline
Hi,
In other applications, I can use primitive properties to drive the texture path in render time (like setting the texture path in the texture node as "<shape.tex_dir>/<shape.name>_diff.tex", where "<shape>" is the primitive and "tex_dir" is a userProperties or user custom attribute.
Does Solaris support such substitutions? Or is there an alternative way to achieve this?
In other applications, I can use primitive properties to drive the texture path in render time (like setting the texture path in the texture node as "<shape.tex_dir>/<shape.name>_diff.tex", where "<shape>" is the primitive and "tex_dir" is a userProperties or user custom attribute.
Does Solaris support such substitutions? Or is there an alternative way to achieve this?
Technical Discussion » Solaris: Material Assign with CVEX and prim userProperties
- Belal
- 15 posts
- Offline
Hi,
How can I automate material assignments based on primitive userProperties in the incoming alembic or usd stages?
I need to do something like this:
Assigning the "skin" material to all primitives that have (userProperties:mat == "skin")
Is this currently possible in Solaris? I couldn't find a node to use to loop over the primitives and access their properties in stage.
How can I automate material assignments based on primitive userProperties in the incoming alembic or usd stages?
I need to do something like this:
Assigning the "skin" material to all primitives that have (userProperties:mat == "skin")
Is this currently possible in Solaris? I couldn't find a node to use to loop over the primitives and access their properties in stage.
Technical Discussion » Feature Suggestion (for better visual representation)
- Belal
- 15 posts
- Offline
One of the main cool things about node based applications like houdini, is the clear visual representation of what's going on during the build of a recipe or when opening a scene made by somebody else...
Unfortunately, this is not the case with houdini scenes due to the fact that we have to keep referencing lots of object paths from/to different nodes where most of the times these nodes are even referenced inside a totally different OP network/subnet.
So, I suggest the following:
1. Allow the OP networks to be expandable (like backdrops - may be using the same UI method with different look)
2. Add a flag in the node view settings that allow hiding/showing the indirect connections between nodes references (the connection lines can be dotted with an arrow showing the direction of the reference connection, and can also be color coded make it clear if this is an object reference or attribute reference).
3. When 'tab' is pressed or the user requested a new node, check if the mouse is over an expanded OP Network, if it is, then filter the possible nodes as how already happening when requesting new node in this type of OP network.
4. Add input ports to nodes like 'object merge', 'dopimport'...etc, so the user can directly connect to them rather than referencing an object path (or maybe create equivalent nodes with nicer names since in this case, it won't be a dopimport or objectMerge, but it will be just a pass through with some parameters).
Unfortunately, this is not the case with houdini scenes due to the fact that we have to keep referencing lots of object paths from/to different nodes where most of the times these nodes are even referenced inside a totally different OP network/subnet.
So, I suggest the following:
1. Allow the OP networks to be expandable (like backdrops - may be using the same UI method with different look)
2. Add a flag in the node view settings that allow hiding/showing the indirect connections between nodes references (the connection lines can be dotted with an arrow showing the direction of the reference connection, and can also be color coded make it clear if this is an object reference or attribute reference).
3. When 'tab' is pressed or the user requested a new node, check if the mouse is over an expanded OP Network, if it is, then filter the possible nodes as how already happening when requesting new node in this type of OP network.
4. Add input ports to nodes like 'object merge', 'dopimport'...etc, so the user can directly connect to them rather than referencing an object path (or maybe create equivalent nodes with nicer names since in this case, it won't be a dopimport or objectMerge, but it will be just a pass through with some parameters).
Technical Discussion » OpenCL on Multiple Separate GPUs
- Belal
- 15 posts
- Offline
christopherwThank you… That what I was looking for to know… I missed that info.
From the system requirements page [www.sidefx.com], at the bottom:
“GPU acceleration currently does NOT make use of multiple OpenCL devices (i.e. two or more graphics cards) but this may change at a future date.”
But one more question… If two cards are linked via NVLink, then is this will be supported due to the link that makes the two as one?
Technical Discussion » OpenCL on Multiple Separate GPUs
- Belal
- 15 posts
- Offline
In theory, from OpenCL development aspect, it's doable by making separate command queue for each device, then they would work as with multithreading, but my question here is if houdini was developed with this taken in account?
I wish to know to see if installing 4 cards in my server will make a difference.
I wish to know to see if installing 4 cards in my server will make a difference.
Technical Discussion » OpenCL on Multiple Separate GPUs
- Belal
- 15 posts
- Offline
Hi,
Is houdini designed to use all the available cuda cores from all the available GPU cards on the system if these cards are not connected together (via nvlink or SLI connection)?
If yes, should we expect any performance improvements in OpenCL simulations if these GPUs are linked together?
Is houdini designed to use all the available cuda cores from all the available GPU cards on the system if these cards are not connected together (via nvlink or SLI connection)?
If yes, should we expect any performance improvements in OpenCL simulations if these GPUs are linked together?
Technical Discussion » Alembic_In sourcecode || userProperties read
- Belal
- 15 posts
- Offline
Hi Derrick,
Thanks for the info.
I played with the userProperties parameter already, but I couldn't have them loaded… is there anything special I should do other than setting the load user properties to either “read values” or “read values and meta data”?
I thought maybe they will not appear in the geometry spreadsheet (since they are not primitive variables, but even when I try to read them in python using hou.node.userData(), it returns None… Do you think I'm using the wrong function to query them?
Note: I'm using AlembicArchive, load as houdini geometry (full scene hierarchy).
Thanks for the info.
I played with the userProperties parameter already, but I couldn't have them loaded… is there anything special I should do other than setting the load user properties to either “read values” or “read values and meta data”?
I thought maybe they will not appear in the geometry spreadsheet (since they are not primitive variables, but even when I try to read them in python using hou.node.userData(), it returns None… Do you think I'm using the wrong function to query them?
Note: I'm using AlembicArchive, load as houdini geometry (full scene hierarchy).
Technical Discussion » Alembic_In sourcecode || userProperties read
- Belal
- 15 posts
- Offline
Hi Everybody,
Is the Alembic_In source code available somewhere for public?
The open alembic project has a 5-6 years old version of the code.
I noticed that the userProperties on alembic objects are not loaded as userData (or anywhere else) when loading alembics, while this is a major thing in our pipeline… (please correct me if I'm wrong).
We can still query the alembic asset file and get what we want using the alembic API, but if this is the only available option, then I would prefer to modify the plugin code to make a build that just have the data gets loaded on request using an addition parameter.
Thanks
Is the Alembic_In source code available somewhere for public?
The open alembic project has a 5-6 years old version of the code.
I noticed that the userProperties on alembic objects are not loaded as userData (or anywhere else) when loading alembics, while this is a major thing in our pipeline… (please correct me if I'm wrong).
We can still query the alembic asset file and get what we want using the alembic API, but if this is the only available option, then I would prefer to modify the plugin code to make a build that just have the data gets loaded on request using an addition parameter.
Thanks
-
- Quick Links