a couple questions for my own curiosity if you don't mind:

-what decides whether a function will become an expression or hscript command?

-in the begining, which was first, and why was the latter implemented after the other? did they pop up at the same time? and if so, why not just keep it to one format?

i guess this comes in response to me getting frustrated because i can't pull up help on functions because i forget that they actually might be an expression rather than hscript.. i go searching for keywords and thinking “i know there's an opthis and an opthat, where the heck is it!?” just to calm down and remember 5 min later that i should of been doing an exhelp -k instead of a help -k.. i would also think it would help with the whole “backtick this, double quote that, make sure you eval() that one first” ordeal..

thoughts anybody? would love to know some background info on this.. also some reasoning as to why ‘one format would be a bad thing’ from you people smarter than i would be nice… :wink:

The way I look at it is this…

Hscript is for managing and changing your hip file. You add nodes, you can query node's parameters, set flags, add keyframes etc. These are all things you can do through the interface.

Now the expression language is for evaluating data. Math functions, fetching channel data, query geometry details, etc.

Now there is some overlap between the two. (pwd and oppwd() for example) In the case of overlap its just there for convenience so you don't have to do run(“command”) all over the place.

yea, what you're saying does make a good point as to the references of each one.. i can digg it..

i was actually about to come back and say “well what about opselect and opflag being expressions then”.. but after i thought about, that too does make sense since they're returning a list rather than setting a property like you would use opset for.. also, i suppose this would go towards your “overlap for convenience” comment which is a good to have..

but i have to be honest and say, my first reaction to:

Now the expression language is for evaluating data. Math functions, fetching channel data, query geometry details, etc.

was “well what about vex then? vex is essentially doing that”.. but i suppose expressions would be much quicker to throw down in a parm rather then setting up something in vex.. i dunno.. it's can get crazy when it comes to all these formats/languages at times..

thanks wolfwood..

VEX and the expression are pretty different too.

Like before, expressions are good at referencing data in different parts of your scene.

VEX on the other hand is really good at processing a single piece of data. Much like an a built-in operator. Give a piece of geometry/channels/particles run this code on every point. In VEX you don't have the large variety of functions as you do with the expression language. You can't get a list of bundles, you can't check flags etc.

hscript: Good at querying the state of your hip file
expresson: Good at referencing data in your hip file
vex: Good at processing an incoming set of data (like a node) in in parallel

The thing with vex is that it's really a shading language and as such pretty much exclusively deals with points and functions you can apply to points, it's been extended into other areas of the package but doesn't and could never fully replace some areas that are the domain of expression or hscript.

Think of it all as a venn diagram - like this :twisted:

thanks guys.. this does make it a lot clearer for me now in respects to each's purpose and reasoning. 8)

I see how the VEX and Expression works, but now does VEX and HScript works…? ops:

It was only half serious, don't take it too literally. :wink:

i suppose you could always use hscript to throw down and wire in an inline vop.. then edit the vex code parm