inline vs snippet and chramp

[mrWolf]

Recently I am using quite a bit the amazing inline and snippet vops in shop context to write volume cvex shaders. Really amazing stuff cause I can pretty much copy and paste the code from an Attribute / Point Wrangle node in sop context.

 

Question 1:

what is the difference , advantages , disadvantages of inline VOP vs snippet VOP ?

 

 

Question 2:

I am trying to use the command "chramp" to manipulate a value in a inline vop in a vopcvex shader with no luck.

I tried the same with a snippet vop, same problem.

 

(test hip file attached)

 

From "snippet" doc:

 

"You can use the VEX function ch to evaluate parameters. The path is relative to this node (ch("parm") will evaluate the parameter parm on this node). This evaluation will be done at the current time."

 

 

chramp is not mentioned but I guess it should work as well.

 

Has anyone experienced anything like that so far ?

(H13.0.476)

 

 

chramp_issue.hipnc

[fathom]

i don't find snippet that useful inside of a vop network.  snippet really only shines in the wrangle wrappers -- inside of vops, it doesn't really offer a ton of utility compared to inline.  snippet's only real big advantage over inline is that it can create parameters directly without having to create actual "parameter" nodes.  which is a marginal advantage in a vop net.

 

as for your chramp problem... chramp isn't valid for shop contexts.  i'm sure it's an issue with mantra not having all the data that goes with your ramp in order to evaluate it properly.  if you view vex code on your shader, you can see your ramp parm variation puts in a lot of code to support the ramp functions, but your inline and snippet variations simply refer to some bit of data someplace (the parm name of your ramp channel on those nodes).  houdini knows where to find that, but mantra does not.  sort of the same issue with doing op: references in vops.

[mrWolf]

i don't find snippet that useful inside of a vop network.  snippet really only shines in the wrangle wrappers -- inside of vops, it doesn't really offer a ton of utility compared to inline.  snippet's only real big advantage over inline is that it can create parameters directly without having to create actual "parameter" nodes.  which is a marginal advantage in a vop net.

 

as for your chramp problem... chramp isn't valid for shop contexts.  i'm sure it's an issue with mantra not having all the data that goes with your ramp in order to evaluate it properly.  if you view vex code on your shader, you can see your ramp parm variation puts in a lot of code to support the ramp functions, but your inline and snippet variations simply refer to some bit of data someplace (the parm name of your ramp channel on those nodes).  houdini knows where to find that, but mantra does not.  sort of the same issue with doing op: references in vops.

Hi Fathom,

thank you for the reply !

 

the chramp issue is quite a limitation if that's considered a 'feature'. Furthermore, if I create a ramp as a parameter to the vopcvex, it works even if it's Mantra who has to deal with it. So I don't see why the same logic cannot be applied to a snippet of code inside the vopcvex.

 

The reason cause this limitation is quite a bummer for me, is because I have an exact replica of a Volume Wrangle , at Sop level, which performs the same job (yes I prefer clean code over a mess of nodes). The Volume Wrangle node has ramps etc (the ramp behavior cannot really be replicated in any other way that I can think of honestly). Then I decided to port the code in a cvex volume shader to have a gridless version. Which works great (even if it's slow like hell). And that's where I just cannot do it other than translating the whole code into vop nodes.

The only partial workaround I found is to use the vex function "smooth(a, b, c)" to simulate a very simple 2 points ramp.

 

Is that really possible that there is no way to use ramps to control the content of Vex code written in a snippet or inline , or, in general, to control ANY vex code applied to a Mantra shader (if there is a different way to write a volume shader)?

Edited August 27, 2014 by mrWolf

[fathom]

you CAN use a snippet or inline code to access a ramp, it's just you can't do it with a chramp() call.  you need to mimic the behavior of the ramp vop which plugs into the ramp parm and pulls values that ultimately end up in a spline() vex call.

 

your problem is that you're creating the ramp parm on the inline code vop.  instead, you should create it as a parm to the shader (you can make it invisible if you'd like).  then you can link the parms of that ramp to the one in your sop version.  this way, the shader knows the full detail of the ramp and you can access it directly with code in an inline node.

[mrWolf]

you CAN use a snippet or inline code to access a ramp, it's just you can't do it with a chramp() call.  you need to mimic the behavior of the ramp vop which plugs into the ramp parm and pulls values that ultimately end up in a spline() vex call.

 

your problem is that you're creating the ramp parm on the inline code vop.  instead, you should create it as a parm to the shader (you can make it invisible if you'd like).  then you can link the parms of that ramp to the one in your sop version.  this way, the shader knows the full detail of the ramp and you can access it directly with code in an inline node.

 

oh !!

that's very interesting !

If I well understood what you're saying, correct me if I am wrong :

You're saying that I can write some code inside the inline vop, and this code will be able to pull the values of a ramp parameter which lives on the shader UI. In other words I've to kinda re-write the chramp function (which is totally ok as long as it can be done with vex calls inside a snippet / inline vop).

 

I added a ramp into a Volume VOP and this is the code snippet related to the ramp.

string ramp_the_basis_strings[]={"linear","linear"}; 
float ramp_the_key_positions[]={0,1}; 
float ramp_the_key_values[]={0,1})
...
float valueToBeRamped;
...
float ramp1 = spline(ramp_the_basis_strings, spline("solvelinear", valueToBeRamped, ramp_the_key_positions), ramp_the_key_values);

I just cannot find the code that actually READS the points from the UI into the float arrays.

 

Are there VEX functions that allow to access the UI of a ramp ?

[mrWolf]

I think I found the answer to my last question, #pragma !

 

http://www.sidefx.com/docs/houdini13.0/vex/pragmas#ramp

and

http://www.sidefx.com/docs/houdini13.0/network/ramps#vex

 

I'll give it a go later this afternoon, thank you Fathom !

[fathom]

you should look at your code of your cvex sample you posted.  the ramp parms in switch 0 case get stuffed into the shader call itself as parameters to the cvex function itself.  basically, it's handled for you by houdini if you make the parameter a true shading parameter.  what you're doing is passing the shader a ramp as a parm just like you could pass it a color or some other value to be used in the shading calculatoin.  when you do it this way, houdini communicates all the ramp information to mantra so it can sort it out.

[mrWolf]

It works great for the Inline vop:

 

I created a ramp parameter in the shader (called "rampfoo"):

 

And I just had to add those lines of code in the inline vop:

 

density=float(spline(rampfoo_the_basis_strings, spline("solvelinear", fit(P.x,-5,5,0,1), rampfoo_the_key_positions), rampfoo_the_key_values));

As far as I understood :

 

• the 3 names rampfoo rampfoo_the_basis_strings rampfoo_the_key_positions rampfoo_the_key_values have to match the name of the ramp parameter (rampfoo).
• you've to create a ramp parameter inside the ramp shader, connect it's input to any thing (for instance life) and then it'll be found by the #pragma (in other words, you cannot create a ramp parameter directly on the UI of the shader only)
• for some reason this doesn't work in a snippet vop, it raises an ambiguous function callto spline())

 

Quite a bit of hacking to get a simple ramp parameter working in an inline vop honestly. But at least it works

Thank you a ton for your help Fathom !

chramp_issue.hipnc

Edited August 28, 2014 by mrWolf

[fathom]

the vex pragmas are only for the ui -- you don't need them in your inline code.  if you coded up your entire shader in straight vex and compiled it with vcc into an otl, THEN you'd need pragmas to define the look of the ui that gets generated around the parms detected by the vcc compile.  other than that, they don't really serve a purpose.


you also don't need to connect the ramp parameter to anything. it just needs to be in the code to trigger the vop network to generate a shader parameter (or in the case of a ramp, a set of shader parameters).


in fact, you don't need to connect any nodes in this situation. you're plugging P into your inline node, but you're referencing "P" directly (ie, the global variable P).  to use the P that's being connected to the inline node, you need to use "$P" in the code.  also, you can remove the $ before "density" and then change the bind to be "always export" (or use a parameter with visibility turned off and exporting turned on, pretty much the same thing to vex).


as for the snippet approach... not sure wtf is going on there. the actual "ambiguous code" problem is not from the snippet, it's from the ramp parm itself. but you don't need the snippet method, so you should be good.


fwiw, i do a TON of inline vops pretty much using the above methods -- i create unplugged parms for my inputs and exports and then inline vops to drive things using direct references to those parms and other globals by name.

[mrWolf]

Fathom this reply helps me a lot.

Thank you for pointing out the $ thing and other flaws in my code, I actually wasn't sure I was using it correctly and this helps a lot.

This method of creating shaders is really handy.

 

Last question:

Is there any advantage in compiling with vcc via command line, over the method we just described ?

The reason cause I ask is that I'd love to find a way to "write" shaders (with code) without going out of Houdini.

 

p.s.

I just tried to remove the $ from $density, and enabling "always export" on the bind, but it doesn't seem to work in my code.

[fathom]

occasionally inline vops won't recognize when you add params/binds after you've written your code.  if it's not recognizing density as a parameter, then click into your inline code and just change something about the text (add a space, then delete it) just to force a recompile ("force recompile" on the vop might also work).

 

i know people who like to write very elaborate vex code in the shell and vcc to compile into otls.  i find the overhead of all of that to be a bit over the top.  there are some advantages to doing out of houdini, but i think the ease with which you can construct your ui and get up and running in little time with the inline vop outweighs any benefit of the external vcc approach.  what's also nice is you can still mix in some things that are useful vops (like noise or pcopen).  you can have classic vops handle the set up and then an inline handle all the logic and math -- the two things that vops really suck at.