Hi All,

I have been looking at the various vop sop techniques I used all the time to complete shots. Now I have been forced to completely change my way of working.I am falling over in a few areas.
See attached and refer to the VOP sop and note how after creating a parameter which appears at the top level of the vop sop I reference a node which is using sop expressions. Something I did all the time.

Then refer to the attribute vop , you can still create the parameters but of course something weird is going on bbox(“../OUT_BOX”,D_XMIN) seems to work and the ramps in both vops have the same values but different end results

So are hscript expressions still valid for use in attribute VOPs or are they incorrect . I would love to hear my workflow is still valid > but why the different Cd.r values between VOPs

Rob

I don't know for sure (hoping someone more knowledgeable can correct/clarify), but I think that because the Attrib VOPs run in the CVEX context (as opposed to VOP SOPs running in SOPs), it changes how/when expressions are cooked. So I'm not sure about how you can/cannot use hscript expressions overall.

Two workflow alternatives: you could save those bbox min/max values of OUT_BOX as detail attributes and reference them directly; or use the bbox vop to read OUT_BOX from AttribVOP's the second input (like the attached screenshot).

My studio saw a few changes to existing workflows with the switch in H14 (we started encouraging Attrib VOP over VOP SOP in H13, to ease the transition), and while the workflow changes were frustrating, ultimately we could get the same functionality. And it was worth all the effor to change, so we could do things like create/destroy geometry in VEX/VOPs (which you can only do in CVEX context).

Hope that's helpful (and I hope someone more experienced can chime in too!)

Thanks for the reply, I figured that it all had to be cvex. Its certainly proving tough , changing the workflow Ive been using since v9.5 days. All those techniques needing to be dumped.

I am assembling a scene file with a whole host of techniques Ive switch over. Some have been painless others like the lack of a all in one technique to set /export / type an attribute are painful , most likely as I am yet to grasp why I even need to set anything lol . After all its not something I ever needed to care about.

Rob

The CVEX vs SOP will not affect how expressions are cooked.

Parameters to your VOPs are all cooked before the VEX code is run, and this behaves the same in the two cases.

ch() calls inside of your VEX code is run during execution, but both SOP and CVEX contexts will run the same code path.

The issue with the inital file is that the two fit1 VOPs are *NOT* wired the same. One wires to srcmin/max, the other to destmin/max. So the difference in behaviour is independent of the CVEX vs SOP issues.

Especially with 14, now that we do detail binding & N computation, things should be pretty equal.

Hi Jeff,

In H14 also AttribWrangle in detail mode doesn't require a null node to be present to generate geometry. Is there some built-in SESI wizardry there? Because there is no Null node inside the Wrangle SOP.

I mentioned this before but was told this wasn't a good design to allow the Wrangle SOP to be a generator by itself.

The Wizardry would be to change the Minimum Inputs to 0 from 1 for the Wrangle and the Attribute VOP.

I found the likely RFE where I claimed this was a bad idea:

This would require the number of mandatory inputs to depend on the parameter values, something we generally avoid.

I do not want the attrib wrangle sop to be a pure generator, because it doesn't make any sense for all cases except this particular case.

It would make more sense for me to create a new sop, a GeneratorWrangler or better named variant, which just has the attribwrangle + null + detail mode.

Fortunately I saw the error of my ways back in April and now you can make them generators.

jlait
The Wizardry would be to change the Minimum Inputs to 0 from 1 for the Wrangle and the Attribute VOP.

I found the likely RFE where I claimed this was a bad idea:

This would require the number of mandatory inputs to depend on the parameter values, something we generally avoid.

I do not want the attrib wrangle sop to be a pure generator, because it doesn't make any sense for all cases except this particular case.

It would make more sense for me to create a new sop, a GeneratorWrangler or better named variant, which just has the attribwrangle + null + detail mode.

Fortunately I saw the error of my ways back in April and now you can make them generators.

Wow thanks Jeff, that was a nice surprise when I noticed it and made me think if I made an error when loading presets in H14 AttribWrangle