Found 1024 posts.
Search results Show results as topic list.
Solaris and Karma » Custom Scripts on Scene Graph Tree context menu
- mtucker
- 4445 posts
- Offline
Solaris and Karma » Import detail attribute create indices?
- mtucker
- 4445 posts
- Offline
What @tamte says is correct, and it is true regardless of the type/interpolation of the primvar being authored, because we have no way to know what type/interpolation of primvar may be getting overwritten by this SOP-generated layer.
Solaris and Karma » Swapping payload in LOP without saving stage first
- mtucker
- 4445 posts
- Offline
The SOP Import LOP has a "Save Path" parameter that lets you control where the USD file generated from the SOP imported geometry should be saved.
Solaris and Karma » Beginner: How do I get USD pyro to animate in viewport?
- mtucker
- 4445 posts
- Offline
It's a bug. Native Houdini volumes expressed in USD don't generate proper hydra updates when their attributes are time varying. VDB volumes work fine.
Don't use the "$F * -1" offset trick. It's working by basically re-authoring the whole volume prim from scratch, causing a potentially much heavier update for the renderer than should really be required. And it's going to introduce a pointless time dependency in your LOP graph increasing cook times.
If you don't like the automatic naming of the volume files output by the USD ROP, set the usdvolumesavepath on your volume primitives in SOPs. The only rule the automatically generated file names follow is that they make functional USD files. There are no promises that the generated names will "make sense".
Don't use the "$F * -1" offset trick. It's working by basically re-authoring the whole volume prim from scratch, causing a potentially much heavier update for the renderer than should really be required. And it's going to introduce a pointless time dependency in your LOP graph increasing cook times.
If you don't like the automatic naming of the volume files output by the USD ROP, set the usdvolumesavepath on your volume primitives in SOPs. The only rule the automatically generated file names follow is that they make functional USD files. There are no promises that the generated names will "make sense".
Solaris and Karma » Identifying which parm is affected by a given 'control' parm
- mtucker
- 4445 posts
- Offline
The relationship actually goes the other way... Each value parm can have a "usdcontrolparm" spare parm tag to point to the parm that should be used as the control parm. Other than that, it isn't actually the name of the parms that matters, but the relative positions of the parms... Control parms affect all value parms that follow it until the next parm that ends with "control".
Solaris and Karma » Get primvar values in parameter fields and wrangle nodes
- mtucker
- 4445 posts
- Offline
If you call `Get()` without an argument, what you get back will be the "default value" of the attribute. If the attribute you are fetching has time samples (or really even if it doesn't have time samples), it's always best to pass a time value to the Get() method. Passing in `hou.frame()` is always a good option but will make your node time dependent. Passing in `0.0` will work if there is a single time sample or if the value is only set as a default value, and will avoid creating a time dependency. But it won't give you the expected result if there are multiple time samples available on the input's stage at the same time.
Solaris and Karma » Asset library path change
- mtucker
- 4445 posts
- Offline
The contents of the Layout LOP are not completely locked. You can dive inside the Layout LOP and you'll be presented with all the nodes that were used to load the assets from disk (probably a bunch of asset reference LOPs). You can modify these nodes to use HIP-relative paths instead of absolute paths. Things can go sideways if you nodes in there, or cause the primitive path where the asset is loaded changes, but otherwise modifying parms on existing nodes should be safe.
Technical Discussion » Solaris Help???
- mtucker
- 4445 posts
- Offline
If you could submit a bug with a simplified hip file that shows this issue it would be much appreciated!
Technical Discussion » How to catch stage update in a python_panel in Solaris?
- mtucker
- 4445 posts
- Offline
My best advice would be to look at how the scene graph details pane is doing it... To describe it at a high level:
1. OnNodePathChanged triggers an update and sets up a bunch of node event callbacks.
2. Triggering of those callbacks checks if there are any unhandled updates outstanding. If so, do nothing and return. If not, set a flag indicating that there are outstanding unhandled updates, and use hdefereval to cause an "update" function to be called when control returns to the UI event queue.
3. The deferred update function updates the panel, and turns off the flag indicating that there are outstanding unhandled updates.
The use of hdefereval is critical for two reasons:
1. It prevents massive over-updating of the panel UI
2. It allows us to follow the rule (that I have been trying to publicize a lot recently): Do Not Cook Nodes in Node Event Callbacks!
My best guess for why your panel is "one cook behind" is because you are violating the rule in (2)?
1. OnNodePathChanged triggers an update and sets up a bunch of node event callbacks.
2. Triggering of those callbacks checks if there are any unhandled updates outstanding. If so, do nothing and return. If not, set a flag indicating that there are outstanding unhandled updates, and use hdefereval to cause an "update" function to be called when control returns to the UI event queue.
3. The deferred update function updates the panel, and turns off the flag indicating that there are outstanding unhandled updates.
The use of hdefereval is critical for two reasons:
1. It prevents massive over-updating of the panel UI
2. It allows us to follow the rule (that I have been trying to publicize a lot recently): Do Not Cook Nodes in Node Event Callbacks!
My best guess for why your panel is "one cook behind" is because you are violating the rule in (2)?
Solaris and Karma » Lightlinker broken
- mtucker
- 4445 posts
- Offline
Solaris and Karma » Point Instancer without Referencing ("Reference" Method)
- mtucker
- 4445 posts
- Offline
The primvar doesn't exist on the instance prims until after the instancer LOP, so the Reference LOP has to come after the instancer. See the attached new hip file.
Technical Discussion » Context Options - (LOPs/TOPs)
- mtucker
- 4445 posts
- Offline
Not for global context options. You can use an "Edit Context Options" LOP to control the in-network value of a context option using an expression, but that's a very different thing. I guess you could have a context option change callback so that when option A changes it recalculates a new value for option B. But if an Edit Context Options node is used to modify option A, the value of option B won't update because there is no change notification for that. But I suppose in an Edit Context Options LOP you could set both option A and option B, but then you're duplicating your expression to set B from the value of A in multiple places...
Solaris and Karma » selecting varient based on logic + reading usd primvar broken ?
- mtucker
- 4445 posts
- Offline
In your VEX LOPs, the problem is that you set it to "run over elements of array", which is a mode used to alter values in array attribute values. Here you don't want that, you want to run the VEX code once per USD primitive, so you should turn off that checkbox. In your python code, the problem is that you are calling Attribute.Get() and primvar.ComputeFlattened() without passing in a UsdTimeCode argument. This causes these function to fetch their "Default" value, which is not set anywhere. All your primvars are time sampled values. You can fix this either by authoring the primvars as default value, or by passing Usd.TimeCode(0.0) to the functions that are pulling out the attribute values.
Also be aware that you are going to be getting back single-value arrays from these functions, so you'll need to index into the array to pull out the actual value of interest.
HTH.
Also be aware that you are going to be getting back single-value arrays from these functions, so you'll need to index into the array to pull out the actual value of interest.
HTH.
Solaris and Karma » viewport camera stuck in previous stage (multishot)
- mtucker
- 4445 posts
- Offline
Technical Discussion » Why the pineapple doesn't have motion blur in Solaris?
- mtucker
- 4445 posts
- Offline
Hi @digitalwu! To make this scene work properly, turn off velocity blur on the karma_preview LOP. There is no velocity information on the pineapple geometry, so telling karma to render velocity blur is basically telling it to not render motion blur. When you stop telling karma to use velocity blur, it falls back to using deformation blur, which is the correct type of blur to use given your input data which has time-sampled point positions.
Solaris and Karma » Extent bounding box not visible in viewport
- mtucker
- 4445 posts
- Offline
If the extent information is in the payload file, then when the payload isn't being loaded, the extent information also isn't loaded. The term "Loft" in "Loft Payload Info" is meant to imply that certain bits of critical information (kind, prim type, and extents) are lofted _out_ of the payload file. So including the output of a loft payload info into the payload is kind of pointless.
If you use a Component Builder setup you'll see that the geometry is what gets put inside the payload, with the extents lofted out of the geometry, but still inside the asset structure. So you reference in the asset (not payload in the asset) and you don't need the loft payload info node. Unloading payloads will unload the geometry (the heavy part of the asset) but leave the top level of the asset and the lofted extent info from the referenced top level asset file (e.g. $HFS/houdini/usd/assets/pig/pig.usd).
If you use a Component Builder setup you'll see that the geometry is what gets put inside the payload, with the extents lofted out of the geometry, but still inside the asset structure. So you reference in the asset (not payload in the asset) and you don't need the loft payload info node. Unloading payloads will unload the geometry (the heavy part of the asset) but leave the top level of the asset and the lofted extent info from the referenced top level asset file (e.g. $HFS/houdini/usd/assets/pig/pig.usd).
Houdini Lounge » Clarisse workflow in Houdini
- mtucker
- 4445 posts
- Offline
In the interest of full disclosure here, you may want to check out the Solaris forum to read up on other people's experiences with the Stage Manager and Layout LOP. I remain convinced that real, useful work can be done with these tools, but I also have to admit that they are not where we (or many users) want them to be. But we are working on it. In the next major release of Houdini the Stage Manager is getting a major revamp in terms of both the parameter pane UI and more importantly the viewport based workflows. The layout LOP has seen some bug fixes since the H20 release, but major improvements to that node will have to wait until the Houdini release after the next one.
Using SOP based workflows in conjunction with the Instancer LOP is also an excellent option for some scenarios (especially more procedurally driven environments), but that workflow will be less "Clarisse-like". than working directly in Solaris. Also the next release will include a couple of big improvements for these SOP based workflows too.
As for a meta-level description of how to build scenes in Solaris, I would strongly recommend splitting the process of asset creation from scene assembly. The bridge between these two workflows will be USD files describing each asset. I would guess from what I've heard from other studios that this division is probably similar to what you were doing in Clarisse. But it does remain a useful division. Although you _can_ dump everything into a big hip file or use HDAs to define your assets, most of the time that will result in much worse performance than using USD files to describe your assets.
So yeah, Solaris isn't Clarisse. Yet We will continue to take inspiration from it, and we are actively working towards closing that gap.
Using SOP based workflows in conjunction with the Instancer LOP is also an excellent option for some scenarios (especially more procedurally driven environments), but that workflow will be less "Clarisse-like". than working directly in Solaris. Also the next release will include a couple of big improvements for these SOP based workflows too.
As for a meta-level description of how to build scenes in Solaris, I would strongly recommend splitting the process of asset creation from scene assembly. The bridge between these two workflows will be USD files describing each asset. I would guess from what I've heard from other studios that this division is probably similar to what you were doing in Clarisse. But it does remain a useful division. Although you _can_ dump everything into a big hip file or use HDAs to define your assets, most of the time that will result in much worse performance than using USD files to describe your assets.
So yeah, Solaris isn't Clarisse. Yet We will continue to take inspiration from it, and we are actively working towards closing that gap.
Solaris and Karma » MATERIAL override in LOP/SOLARIS, reading primvar
- mtucker
- 4445 posts
- Offline
Sorry, I'm a bit confused... Your hip file works as is, at least when rendering with karma... I actually thought this would work with Houdini GL as well but it appears not.
Solaris and Karma » Workflow for heavy animated geometry sequences.
- mtucker
- 4445 posts
- Offline
I assume you have per-frame BGEO files to describe your animation? And your problem is that you are currently converting the sequence of BGEO files into a single large animated USD file which takes a long time?
If so, then yes, your best bet is to use the Geometry Clip Sequence LOP to author a value clip. There are many other threads on the forum here talking about how to optimize that process (because if you're not careful this can still force the loading of all the BGEO files when trying to generate the value clip).
If so, then yes, your best bet is to use the Geometry Clip Sequence LOP to author a value clip. There are many other threads on the forum here talking about how to optimize that process (because if you're not careful this can still force the loading of all the BGEO files when trying to generate the value clip).
Solaris and Karma » Retiming value clip instances
- mtucker
- 4445 posts
- Offline
For looping you can create a explicitly looping animation that is long enough to cover your whole animation frame range, or you have to use value clips. The geo clip sequence LOP has parameters for setting up simple looping behaviors.
-
- Quick Links