I have a mesh created using a SOPCreate in USD, I also have a wedge TOP with three wedge attributes. For the target parameter I have it pointing towards; /mat/principalshader1/basecolorr then for the attribute name I have basecolorr and I have this path two additional times with basecolorg and basecolorb but my object is not visible in the viewport ?

I've watched numerous tutorials on USD and PDG (TOPS) but this is not working together.

Can you attach a .hip file with your setup, either here or via a support ticket?

Hi, I decided to do both, support and here.

When going into the TOPS context I have a wedge which is suppose to change the rotation of the cushion which is a parameter linked within a wedge. Although how do I preview each work item which is suppose to change the rotation of the cushion within TOP's ?

First, make sure that the geometry that's being wedged is already visible in the viewport. TOPs doesn't change the visibility of anything when selecting work items, it just applies the wedge values to the scene. Then, on the Wedge TOP itself, enable the "Overwrite Target Parameter on Work Item Selection" toggle. That allows the Wedge node to update the target parameter values when you select a work item in the TOPs UI.

That works fine with the file you have attached, however your wedge node is setting the rotation to values between 0 and 0.7 which was barely visible to me. I changed the upper bound to 90 instead.

That was helpful

Although I see what the problem is, it's rotating the whole chair; rather then just an object of the chair. In the transform1 SOP within, a SOPCreate in LOPS I have the expression @pdg_output(0,"",0) but I'm getting an error on that transform1 SOP that this variable is not found ?

That's not valid syntax. It should either be the function pdgoutput(0, "", 0) or use an attribute accessor like @pdg_output.0.

This expression; pdgoutput(0,"",0) gives an error; although this expression @pdg_output.0 works but it appears that even though I have a point expression on the pivot translation of a transform sop within a SOPCreate, that point expression on the pivot translate is being overwritten by the @pdg_output() expression on the same translate1 sop RotateX parameter ?

Therefore instead of having the wedges which should explicitly effect only the one object of the chair it's effecting the whole object.

What's the error? pdgoutput(..) and @pdg_output return the nth output file path from the selected work item, as a string value.

tpetrick
What's the error? pdgoutput(..) and @pdg_output return the nth output file path from the selected work item, as a string value.

Upon checking the wedge top properties; the channel which has the expression, pdgeoutput.0 is being picked up although it's rotating the whole chair; I didn't understand the rest of you question ?

As for the error from the @pdg_output() expression that is; unable to evaluate expression (/stage/sopcreate1/sopnet/create/transform1/rx)

The pdgoutput function returns a file path as a string value, so it can't be used in an expression on a floating point or integer parameter. It's specifically for querying the nth output file from the selected work item (see https://www.sidefx.com/docs/houdini/expressions/pdgoutput.html [www.sidefx.com] for details). Can you attach an updated example file showing how you're trying to use it?

In the attached scene within LOPS of a SOPCreate node; there is an point expression on the pivot translate parameter of a transform sop. Although the rotateX parameter of the transform sop is what I want the wedge to work on. As the point() expression on the pivot translate is what explicitly rotates only the cushion part of the chair but that isn't working ?

Therefore I was attempting to use the @pdg_output.0 but as you mentioned that returns a string value and the pdg_output() expression returns the error; unable to evaluate expression.

@pdg_output and pdgoutput(..) are two different ways of doing the exact same thing -- one is a local variable and one is function that takes some additional arguments. They're both used to query the output files of the active work item and both of them return a string value, which is the file path to that output file. Work items in the wedge node have no output files, so when a wedge work item is selected in the UI both @pdg_output and pdgoutput(..) will evaluate to empty string. If you try to use pdgoutput(..) as the value for a float or int parameter, HScript will throw an error because the type is wrong for the parameter. If you try to use pdg_output(..) it will throw an error because that function does not exist -- there should be no underscore in the function name.

For the .hip itself, one of the issue I can see is that the wedge node is pushing values to a parm on the SOP Create LOP, but the ROP Geometry is pointing to the output node inside of the SOP Create's SOP network. The ROP Geometry will be writing out the geometry of that SOP network, which means the wedged parameters will no effect on the ROP Geometry because they're being applied at the LOP level. The same is true for previewing the wedge variations -- if the SOP network itself is displayed then clicking on the wedge work items won't change the geometry in the viewport. The previewing will only work if the SOP Create is displayed.

If you want to rotate a subset of geometry, you should change your wedge node to point to the parameters that control that geometry instead of wedging the RX parameter on the SOP create. That can be done by changing the "Target Parameter" on the wedge to point to whatever that parameter is, for example /stage/sopcreate1/sopnet/create/transform1/rx.

Another alternative is to use @CushionRotate in the parameter that you want to use to rotate the geometry -- this is pull instead of push based wedging: https://www.sidefx.com/docs/houdini/nodes/top/wedge#push [www.sidefx.com]

If you want to rotate a subset of geometry, you should change your wedge node to point to the parameters that control that geometry instead of wedging the RX parameter on the SOP create. That can be done by changing the "Target Parameter" on the wedge to point to whatever that parameter is, for example /stage/sopcreate1/sopnet/create/transform1/rx.

Using the pull method I applied @CushionRotate to the /../../../../transform1/rx parameter but this still rotates the whole chair ? Although the wedge is effecting the parameter for the /transform1/rx using the pull method. I can't figure out why the whole chair is still moving ?

I'm not sure. I don't have your input geometry file, so I'm not able to see exactly what's happening. On the wedge node, make sure to disable the Target Parameter otherwise the wedge will continue to be applied to that parm. Also, make sure the rotation parameters on the SOP Create are reset back to their defaults.

I've been testing with the default.bgeo file in the File SOP, and updated the Group node to select the first two prims (1-2). Only those prims rotate if I set transform1/rx to @CushionRotate, and then click through the wedge variations. Likewise when cooking the ROP Geometry.

Alright, I checked the scene again; and this time it's working. Thanks for the help to iron out what I was doing wrong.

Although, I must have read this quote a few times; and I didn't quite understand ?

For the .hip itself, one of the issue I can see is that the wedge node is pushing values to a parm on the SOP Create LOP, but the ROP Geometry is pointing to the output node inside of the SOP Create's SOP network. The ROP Geometry will be writing out the geometry of that SOP network, which means the wedged parameters will no effect on the ROP Geometry because they're being applied at the LOP level. The same is true for previewing the wedge variations -- if the SOP network itself is displayed then clicking on the wedge work items won't change the geometry in the viewport. The previewing will only work if the SOP Create is displayed.

In your original file the wedge was pushing parameters to the SOP Create LOP node, but your ROP Geometry is pointing to the SOP network inside of that LOP. No matter what parameters are set on that LOP node, nothing will affect the behavior of the SOP itself. The wedging only applies changes at the LOP level. Since the ROP Geometry is cooking the SOP, the wedge has no effect on the output of the ROP Geometry.

The same thing is true with object networks. For example if you have a cube created in /obj, and point the ROP Geometry to the SOP node. If you change parameters on the object at /obj level it will have no effect on the output of the ROP Geometry, because the ROP Geometry is not cooking the object. It's cooking the SOP inside.