Found 1017 posts.
Search results Show results as topic list.
Technical Discussion » Solaris Help???
- mtucker
- 4435 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
- 4435 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
- 4435 posts
- Offline
Solaris and Karma » Point Instancer without Referencing ("Reference" Method)
- mtucker
- 4435 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
- 4435 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.
- mtucker
- 4435 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
- 4435 posts
- Offline
Technical Discussion » Why the pineapple doesn't have motion blur in Solaris?
- mtucker
- 4435 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
- 4435 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
- 4435 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
- 4435 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
- 4435 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
- 4435 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.
Solaris and Karma » MATERIAL override in LOP/SOLARIS, reading primvar
- mtucker
- 4435 posts
- Offline
I don't know if redshift is capable of this, but I would expect it is... The key thing is that your material needs to have a "primvar reader" node to let it know it should be looking for the textureReader primvar on the geometry to determine which texture to load. Attached is an example that shows a couple of different ways of setting such primvars. In both cases the material is a simple USD preview surface with a UV Texture node driving the diffuse color, and a primvar reader node driving the file input of the UV Texture node.
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4435 posts
- Offline
am_wilkins
@mtucker: The goal is just to ensure that the incoming "prototypes" randomize between the variants. While having an intuitive/neat workflow. Cause right now, spamming the same asset ref USD multiple times seems really strange workflow.
I'm not sure what might be going wrong in your setup, but it's certainly possible to make things work as expected (see attached file). The "trickiest" part was realizing that the instancer LOP have to turn off the option to only import the prototype prims... Because the per-variant prims are references to another prim in a different part of the scene graph, you can't _just_ copy the per-variant prims onto the instancer stage.
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4435 posts
- Offline
flipsideza
I might be doing this wrong, but something I have been playing with is using a `for each` loop.
The problem here is that you only have one "copy" or the asset in your scene. So in the for each loop, each iteration is setting the variant selection _on that same scene graph location_ to different values. So the last one wins. If you move the asset reference _inside_ the for each loop, and use the ITERATION context option to make a unique asset reference location for each iteration, then you will end up with multiple references to the asset, each with a different variant chosen.
If you take this approach, then you also don't want to feed the asset to the for each first input, because then you'll end up with one too many copies of your asset in the scene (the stage connected to the first input is "passed through"). So you'd want to also connect the asset reference to the _second_ input of the for each LOP, and iterate over variants on the second input. The stage connected to the second input is not made part of the output of the for each LOP.
I've attached a hip file that demonstrates this.
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4435 posts
- Offline
Solaris and Karma » Creating explicit save layers with Python
- mtucker
- 4435 posts
- Offline
One more thing you need to do to get the USD ROP to save your anonymous layers: create the anonymous layer with a "tag" argument of "LOP". This is how the USD ROP identifies layers as having been authored by the LOP network.
Note that everything else you're doing here is correct, and in fact there is a python method loputils.createPythonLayer that encapsulates all this so you don't actually need to know all these details. Just pass it the hou.LopNode that is creating the layer (hou.pwd() when inside a Python LOP) and pass in a save path where you want the layer to be saved.
Note that everything else you're doing here is correct, and in fact there is a python method loputils.createPythonLayer that encapsulates all this so you don't actually need to know all these details. Just pass it the hou.LopNode that is creating the layer (hou.pwd() when inside a Python LOP) and pass in a save path where you want the layer to be saved.
Solaris and Karma » Correct way to get instancer using variants
- mtucker
- 4435 posts
- Offline
Try turning off the "Create References" toggle on the Explore Variants node? I believe that will eliminate the reference arc above the individual variants, allowing each variant to be safely copied into the instancer's prototypes folder.
Solaris and Karma » Usd render scene issue
- mtucker
- 4435 posts
- Offline
Since you mention "work items" I assume you're using TOPs as well, not a vanilla USD Render ROP? Any chance you could attach a simple hip file to demonstrate your setup? Thanks!
-
- Quick Links