Found 1001 posts.
Search results Show results as topic list.
Solaris and Karma » Storm render to disk
- mtucker
- 4417 posts
- Offline
You can use a USD Render ROP if you change the Render Command (on the Output tab) to `usdrecord` instead of husk (or `usdrecord.cmd` on Windows). If you do this, not all of the parameters will work of behave the same way because husk provides a lot more command line options than usdrecord. But usdrecord will run Storm as the renderer.
Solaris and Karma » Solaris material gallery?
- mtucker
- 4417 posts
- Offline
It is possible to make a new material catalog, but we haven't exposed a UI for it the way we did with the Component Builder's ability to add your new asset to an asset gallery database.
If you're willing to run some python code, you can use the assetutils.MaterialGallery.addMaterialsFromFile method to add materials from a USD file on disk to a material catalog database. We are hoping to provide a nice workflow for this, but first we need to work out tools for authoring sensible sets of materials (where a generic base material is specialized to create a bunch of specific materials). So no promises on when this will appear, but we are aware of this missing piece.
If you're willing to run some python code, you can use the assetutils.MaterialGallery.addMaterialsFromFile method to add materials from a USD file on disk to a material catalog database. We are hoping to provide a nice workflow for this, but first we need to work out tools for authoring sensible sets of materials (where a generic base material is specialized to create a bunch of specific materials). So no promises on when this will appear, but we are aware of this missing piece.
Solaris and Karma » randomizing instances with looped prototipes
- mtucker
- 4417 posts
- Offline
Looping is best handled using Value Clips in USD. Use the Geo Clip Sequence LOP in H20 to (relatively) easily create a value clip with looping animation. Then reference this value clip looping animation as a prototype to use in an Instancer LOP. This will give you a point instancer with all identically timed looping animations. Then use a Retime Instances node to assign different offsets in the animation to each instance.
If your shot goes from 1000-1500, you should be fine to create a looping animation of length 550, then make sure all your offsets generated by the retime instances LOP are in the range (1000, 1050). Of course with value clips, generating a loop that is 1500 or 15000 frames long should be no problem, and won't affect the size of the USD much at all.
If your shot goes from 1000-1500, you should be fine to create a looping animation of length 550, then make sure all your offsets generated by the retime instances LOP are in the range (1000, 1050). Of course with value clips, generating a loop that is 1500 or 15000 frames long should be no problem, and won't affect the size of the USD much at all.
Solaris and Karma » USD Export to glTF
- mtucker
- 4417 posts
- Offline
There is ongoing work in the USD/gltf communities to creating a USD/gltf file format plugin. You might want to look on the AOUSD forum for any news or updates. I don't think SideFX is likely to be the ones to implement such a plugin, as there are other parties that have a bigger stake (and more resources) to tackle this. If this work is open sourced you should be able to build it as a plugin to Houdini's USD library. Or if it reaches sufficient quality and the licensing allows it we could make it part of Houdini's USD distribution.
Solaris and Karma » Geometry Clip Sequence Lop or how to handle large data
- mtucker
- 4417 posts
- Offline
Indeed. Please give it a try and let me know if the performance has gotten to where you want it to be. Thanks!
Solaris and Karma » Using hscript to control display of objects
- mtucker
- 4417 posts
- Offline
You _can_ implement something in the scene graph tree, but remember that changes made there _only_ affect the viewport. They will never affect your final render. Given that your current approach creates a node, I assume this change in behavior would be undesirable. But using a node I think isn't a big deal if you give the node a particular name based on what it does (clear_render_visibility) and every time you want to hide a prim, add it to the Primitives parameter of this existing node (or create the node if it doesn't exist yet).
Solaris and Karma » Update parameters scripting syntax
- mtucker
- 4417 posts
- Offline
hscript has the encodeparm() function. So you could make this more legible by doing:
opparm RGS_lop_for_object `encodeparm("primvars:karma:object:rendervisibility")` ( "-primary" )
opparm RGS_lop_for_object `encodeparm("primvars:karma:object:rendervisibility")` ( "-primary" )
Edited by mtucker - Dec. 21, 2023 19:28:44
Solaris and Karma » Scene Graph Tree vs Collections, why the column difference?
- mtucker
- 4417 posts
- Offline
Thanks! It's so nice to get validation that we're heading in the right direction from someone that I know will be honest
Mark
Mark
Solaris and Karma » Edit Lop does not smooth as OBJ context
- mtucker
- 4417 posts
- Offline
Oh, sorry, I totally misunderstood this. I thought you were saying that transforming the prims was slow (i.e. dragging the transform handle around). The video makes this much clearer, thanks!
Solaris and Karma » Scene Graph Tree vs Collections, why the column difference?
- mtucker
- 4417 posts
- Offline
Hi Peter! Long time no see!
The reason for the different UI is performance. Showing toggles for the Collection API section would requires maintaining a list of every prim in every collection, and comparing that list of (possibly tens of thousands) of prims against the list of currently selected (or visible, or activated) prims so we could show the correct state of the check boxes. And we'd have to redo this calculation every time the LOP nodes recook.
Also, often we'd be in a state where some of the prims in the collection would be in state A, and some in state B, leading us to want both the "set all on" and "set all off" UI anyway - though showing the "current state" accurately is reason enough to want this UI to change IMO.
Maybe not a satisfactory reason, but you did phrase this in the form of a question
The reason for the different UI is performance. Showing toggles for the Collection API section would requires maintaining a list of every prim in every collection, and comparing that list of (possibly tens of thousands) of prims against the list of currently selected (or visible, or activated) prims so we could show the correct state of the check boxes. And we'd have to redo this calculation every time the LOP nodes recook.
Also, often we'd be in a state where some of the prims in the collection would be in state A, and some in state B, leading us to want both the "set all on" and "set all off" UI anyway - though showing the "current state" accurately is reason enough to want this UI to change IMO.
Maybe not a satisfactory reason, but you did phrase this in the form of a question
Solaris and Karma » More than one layout nodes will cause problems
- mtucker
- 4417 posts
- Offline
In that case I am unable to reproduce. Please submit a hip file, video, and/or detailed steps that will show me how to make this happen. Thanks!
Solaris and Karma » Setting Stage Frame Range with Python
- mtucker
- 4417 posts
- Offline
To quote the documentation for the Python LOP:
There an an existing RFE to allow setting root prim metadata like this with the python LOP, and we have an idea on how to accomplish it, but the facility does not currently exist. For now you must use a Configure Layer LOP to set this kind of stage level root prim metadata.
You must not edit the root layer of the stage. Although this root layer is accessible through the Python API, the LOP cooking architecture requires that it be free to manage that root layer free from interference from any single LOP node.
There an an existing RFE to allow setting root prim metadata like this with the python LOP, and we have an idea on how to accomplish it, but the facility does not currently exist. For now you must use a Configure Layer LOP to set this kind of stage level root prim metadata.
Solaris and Karma » Viewport in Solaris doesn't show anything.
- mtucker
- 4417 posts
- Offline
What version of H19.5 exactly? How are you bringing your geometry from /obj into /stage? Can you provide a hip file? Thanks!
Solaris and Karma » Can we control size/rotation seperately with the place tool?
- mtucker
- 4417 posts
- Offline
Solaris and Karma » More than one layout nodes will cause problems
- mtucker
- 4417 posts
- Offline
This is a known issue in the case where you are changing the asset gallery database (the choice of asset gallery database is currently global and affects all layout LOPs, and the working set can only refer to assets in the current asset gallery). There is an RFE to address this.
But if you are using the same asset gallery database for all the Layout LOPs, in my testing with the latest H20 builds, the individual working sets for each layout LOP are preserved. Please try the latest H20 build because an issue around this was recently fixed (though the issue was that the working set entries would "multiply" when switching from one Layout LOP to another).
But if you are using the same asset gallery database for all the Layout LOPs, in my testing with the latest H20 builds, the individual working sets for each layout LOP are preserved. Please try the latest H20 build because an issue around this was recently fixed (though the issue was that the working set entries would "multiply" when switching from one Layout LOP to another).
Solaris and Karma » Geometry Clip Sequence Lop or how to handle large data
- mtucker
- 4417 posts
- Offline
It is technically necessary for writing out the value clips correctly. Generating a correct value clip requires generating a manifest file. Generating a manifest file requires loading the scene graph hierarchy of every clip file, and looking for time sampled attributes, but doesn't actually look at any of the attribute _values_. If your source files are USD this is all super efficient and fast, because USD just loads the bits of the file it needs (hierarchy information, basically). If your source files are BGEO files, getting the "USD hierarchy" of the BGEO file requires doing a full load of the BGEO file into memory and a full translation of the BGEO data into equivalent USD data. This is obviously way more expensive than making the equivalent queries on USD files.
We have two options to address this problem. One would be to rewrite the BGEO file format plugin to allow it to more efficiently extract just the hierarchy information. This would be very complicated and risky, and may not even help that much given how complex the translation from BGEO data to even a USD scene graph hierarchy is. So this isn't likely to happen any time soon.
The other option (which already exists as an RFE) is to provide a checkbox on the Geo Clip Sequence LOP that says "trust me, my scene graph hierarchy doesn't change from file to file, just generate the manifest from the first BGEO file". This will make the "multi frame" cooking mode of the Geo Clip Sequence very fast even for BGEO sequences as it will only need to load one BGEO file to create the manifest. Of course depending on your BGEO sequence, turning on this check box may generate an incorrect manifest file, but at least you'll be able to control this tradeoff between speed and "correctness". We don't have a timeline for this change, but this issue does keep coming up.
And yes, we definitely need to put out more information about this process.
We have two options to address this problem. One would be to rewrite the BGEO file format plugin to allow it to more efficiently extract just the hierarchy information. This would be very complicated and risky, and may not even help that much given how complex the translation from BGEO data to even a USD scene graph hierarchy is. So this isn't likely to happen any time soon.
The other option (which already exists as an RFE) is to provide a checkbox on the Geo Clip Sequence LOP that says "trust me, my scene graph hierarchy doesn't change from file to file, just generate the manifest from the first BGEO file". This will make the "multi frame" cooking mode of the Geo Clip Sequence very fast even for BGEO sequences as it will only need to load one BGEO file to create the manifest. Of course depending on your BGEO sequence, turning on this check box may generate an incorrect manifest file, but at least you'll be able to control this tradeoff between speed and "correctness". We don't have a timeline for this change, but this issue does keep coming up.
And yes, we definitely need to put out more information about this process.
Solaris and Karma » Edit Lop does not smooth as OBJ context
- mtucker
- 4417 posts
- Offline
This usually happens because the edit LOP is higher up the LOP node chain, and when you change something in the Edit LOP, all the downstream LOP nodes also have to recook, resulting in slower interactivity. Do you still see this issue when the Edit LOP is the node with the display flag? A video (or better yet a hip file) could really help clarify the issue, since I have often used the Edit LOP and the performance is generally pretty good...
Solaris and Karma » Creating collections using Python
- mtucker
- 4417 posts
- Offline
You python code isn't correctly creating the CollectionAPI. To add a new collection to a prim, you need to call UsdCollecitonAPI::Apply (https://openusd.org/dev/api/class_usd_collection_a_p_i.html#a4c9c1226d01a049864cc0d437900c458). This adds the metadata to the prim indicating that the collection exists. The code you've written just creates some attributes that are associated with a collection with a particular name, but doesn't actually register the collection instance on the prim.
Solaris and Karma » USD Import SOP and Materials
- mtucker
- 4417 posts
- Offline
IF you want to preserve the USD-ness of your source data, then you need to brings LOPs into your workflow. Rather than loading the USD file directly into SOPs, load the USD file into LOPs, then use SOP Modify or similar LOP nodes to tweak the USD in the SOP context. The workflow here is far from perfect, and we are looking at ways to improve it. But even now you can have a viewport pinned to /stage where the final USD output can be visualized with materials, lights, and everything else from the USD file. But in your network editor (maybe with a second viewport pointed at the SOP network) you can be doing your actual work at the SOP level.
Solaris and Karma » How to export volumes that appear-disappear to a USD file?
- mtucker
- 4417 posts
- Offline
Various places in LOPs where multiple frames of USD are stitched together (Cache LOP, USD ROP, USD Render ROP) have a toggle to "Track Primitive Existence to set Visibility" which creates an animated Visibility attribute on primitives when the source data (usually coming from time varying SOP geometry) pops in and out of existence. This toggle is designed for precisely this purpose.
-
- Quick Links