Some confusion concerning

[TheDunadan]

Some slight confusion over here concerning VEX, hscript and expression language in houdini. In Maya in some way writing an expressions or a MEL script is more or less the same, they both share the same syntax, can contain loops etc. Now back to houdini:

Let's assume I have some really messy expression on Particles that involves a couple of for loops, temporary variables etc. In houdini if I create an expression on an attribute it seems to me, that a typcial expression cannot hold structures such as for loops or temp variables. You have to directly write the expression in such way that it evaluates into the final value for your attribute in a single line.

I saw in the help that you can extend the expression language by writing custom expression functions. Am I missing something or is it the "usual" way to define a custom expression function if the expression you have in mind gets more complex and you cannot write it into a "single line expression".

The syntax for creating the custom expression functions looks very similar to VEX (well .. both are kinda C). VEX gets compiled and will be likely faster than any expression; If I understood the docs right VEX has the limitation of only being able access and write certain context dependent variables, e.g. for particles we have only access to position, velocity, acceleration,... and couldn't directly access custom particle attributes or write to these, while expression haven't got that limitation. Nontheless quite often this will be all the information I'd be intrested in / need. Still can I pass any custom attribute even if it is on a perParticle basis into a VEX operator as arguments. To make things a bit more tricky: for whatever reason I want to use VEX to edit a custom attribute that VEX has no access to usually, therefore I simply let my VEX op write it's output on the P attribute of my particle system. Now I want to write this P attribute on my custom Particle Attribute. Could I simply write on that attribute an expression such as "Mycustomattribute = $PX"; Which $PX would this expression try to grab. Would it simply try going up the OP Graph and get the current Position Vector P? As I only used the P Vector as temporary place holder I created a second branch from my original POP network before i plugged it into my custom VEX POP OP . Now I want to get back my old P Values and replace the VEX modified P Vector. How could I do this and how would houdini know which P I want? (Hopefully the text isn't as confusing as I'm confused )

I remember too well from Maya that once the particle count gets higher and you have a fair number of expressions things get slower and slower and I often wished for some way to compile my expressions / mel code. Houdini has VEX and it gets compiled and I assume on arithmetic operations it'll be pretty fast as no further interpretation is needed as with any script language. My question: Is it advisable trying to create a VEX POP for complex expressions due to efficiency or are the custom expression functions almost as efficient in evaluation ?

My last question (for now) is. expressions or VEX cannot be used actually create new points, geometry etc. Now, how would I tackle the following problem: I have a particle system and some nice L-System and I want that if a particle collides with a surface a new instance of my L-System is created and it starts growing and some parameters of my L-System are effected by the particle attributes that "gave birth" to this new instance of my L-System object. Is there a nice and easy solution for this or does this possibly require hscript, and if so could an expression or VEX code "fire off" a hscipt ?

Thanks for any answers on this

Jens

Tomorrow morning, i'll track down all the spelling booboo's

[Mario Marengo]

Hi Jens,

Am I missing something or is it the "usual" way to define a custom expression function if the expression you have in mind gets more complex and you cannot write it into a "single line expression".

Yep. I'd say expression functions are the usual way of implementing something that is a bit (just a *tiny* bit) more complex than a one-liner. In terms of execution speed, however, VEX is a lot faster and is generally a better approach for complex stuff (although they are both "interpreted" -- expression functions from ascii, and .vex from machine-independent byte-code. i.e: neither are loadable architecture-dependent object code; for that you need the HDK).

If I understood the docs right VEX has the limitation of only being able access and write certain context dependent variables, e.g. for particles we have only access to position, velocity, acceleration,... and couldn't directly access custom particle attributes or write to these

Manipulating attributes is pretty much what vex is for. So yes, you *can* modify any attribute (context globals such as position P, velocity v, etc. *or* your own custom attributes). If you add an AttributePOP and define a vector attribute called "dunavec" you can manipulate it inside a custom vexPOP as easily as the attribute P. To pull them into your vexPOP network you'd use the "Import Attribute" VOP (or, equivalently, use the import() family of functions if you're coding vex directly). There's no need to hijack P to do any of the things you mention.

My question: Is it advisable trying to create a VEX POP for complex expressions due to efficiency or are the custom expression functions almost as efficient in evaluation ?

Use VEX (through VOPs or directly; whichever you prefer) for any non-trivial processing. Not only is vex faster, but it also gives you a lot more power. Unless the expression function is so insignificant that the difference isn't as noticeable (but this doesn't appear to be your case).

I have a particle system and some nice L-System and I want that if a particle collides with a surface a new instance of my L-System is created and it starts growing and some parameters of my L-System are effected by the particle attributes that "gave birth" to this new instance of my L-System object.

Off the top of my head, I'd first look into some copy-stamp solution. Also consider the possible benefits of throwing CHOPs into the mix. You are talking about emulating loops in the geometry-generation stage, however, so it may get tricky. If everything fails, you might be forced to do it in multiple separate passes -- i.e: linearize the logic; "unroll" the loops (but this could get pretty painful, so it's very much a last-ditch solution).

If you're really stuck, then consider preparing and posting a *simple* version of the problem, and hopefully someone here can help

Cheers!

[TheDunadan]

Thanks a lot for the detailed answer

[TheDunadan]

... and i just ran into the first problem

I'm trying to create a simple very simple VEX POP, that simply takes some input vector, and applies that to the color of the Particles.

The code could hardly be any simpler

 pop

pop1(vector input_curve = { 0, 0, 0 })

{

[edward]

I think the problem is that LIFE is a local variable that would only exist in certain operators. So you would need to replace $LIFE with the equivalent expression using point(). Make sure that you're also using this expression in POPs and not under VOPs.

Also note that VEX is a usually faster than the Point SOP because it's a SIMD engine. Thus it will use MMX instructions if possible. Also because it's a SIMD engine, it can't create geometry right now. I find that it's easy enough to work around though by adding geometry in SOP land.

[TheDunadan]

sorry, couldn't follow you there.

primuv("/obj/model/controlCurve", 0, "P", 1, 1 , 0.0)     0     0

works fine and it's outside the VOP. It's just the single input parameter and I don't see how using point() to extract the info on the control curve would help the $Life issue.

I attached my lil scene file and maybe this will make it a bit clearer. Looking at the scene file you might have some clue about my actual purpose of all this

noLife.zip

[edward]

Sorry, I wasn't thinking. point() won't work as you don't know what your current point/particle number is.

Here's a longer explanation on how $LIFE works. What you want out of it is for the primuv() expression to be evaluated for *each* particle. Only special operators evaluate the parameters again for each point/particle. That's why it works in the Color POP or the Point SOP. For all the non-special operators (eg. VEX operator), it won't re-evaluate the parameter differently for each point/particle. That's why it doesn't work.

I think that you should just build your curve look up using the Spline VOP to do the colour.

[TheDunadan]

Ah ok, well i don't want the spline VOP for the color part. What I had in mind was to create a twister like thing and I wanted an easy to control --> use curves as input:

e.g. one curve that does the overall shape, another one that drives the width, etc. I don't want to use the orbit POP for the rotation part, but much rather modulate the forces and therefore write a couple of VEX POP'S that calculate the appropriate acceleration etc. Having splines to visualize the different attributes would have been the most "artist friendly" way of doing it, I think.

If I got you right, the best way to bypass that problem would be using the vertices of my actual SOP curve as parameters for a spline that is created in the VOP.

Have I ever mentioned I wished Houdini had this kinda ramp / curve input Operator for VOP's Still can't get used to either rendering an COP Ramp to an image and thus using the COP Ramp indirectly or creating splines wich don't have a direct visual feedback

[Mario Marengo]

Hey Jens,

What Edward said; but there is a simple solution.

One thing is to modify attributes (which you now know can be done easily). But using a local variable label that the expression parser can understand as a reference to an attribute, is a different thing altogether. If I had to make a (somewhat educated) guess, I'd say the symbol "$LIFE" (or $V" or "$PT", etc.) normally maps to a predetermined attribute, only because the OPs that provide it both define and expose it for you. Your custom OP (POP in this case) can't get at the original mapping and therefore can't make it available for you to use in a local expression. The root of the problem then, is that these mappings are private to the factory OPs, and can't be emulated in custom OPs. Additionally; this means that the mappings are volatile; they don't automatically carry from OP to OP -- their life begins and ends with the cooking of each OP that defines them.

However; there *is* one type of mapping that gets carried along from OP to OP. These are the "Local Variable" translations that an AttributePOP (or AttribCreateSOP) create. I believe these are stashed with the detail -- which is the only "thing" that gets passed between OPs -- and so remain accessible accross OPs.

So; a simple solution to your problem would be to:

Insert an Attribute POP sometime before your custom POP (but *after* the value of $LIFE is fully defined) and use it to create your own (persistent) version of "$LIFE". Set its name to, say, "mylife"; leave the "Local Variable" field empty for an automatic mapping to "MYLIFE" or set the symbol explicitly. Leave the default at zero, and in the Value field, put the reference to the real variable: $LIFE. From this point on, you can use the proxy local variable "$MYLIFE" in your custom OPs.

I'm attaching a quick sketch (a microscopic hip is woth a thousand words )

Cheers!

duna1.zip

[edward]

Mario, that doesn't work though. You'll notice that the colours on all the particles are the same because the parameter is only evaluated once.

Dunadan, what you want to do is still possible. You just have to figure a way to do it inside the vopnet as you have access to the point numbers in there.

[Mario Marengo]

Mario, that doesn't work though. You'll notice that the colours on all the particles are the same because the parameter is only evaluated once.

Oooooops... yup; screwed that one up, sorry!

The attribute mapping works as expected (I was looking at the spreadsheet and saw the numbers matching, so in my "Saturday Lazines" I thought "problem solved!"), but of course, parameters get evaluated only once... DUH!!

@Edward: I'm thinking this whole "make VEX attributes map to local vars" issue should become an RFE; but since you know about the internals of the OP architecture, do you think it would even be possible to, say, add a "Map to Local Variable" abitlity to the ImportAttribute VOP (or the import() functions)?

@Jens: I think you'll have a hard time getting the functionality of that expression into vex -- I see it more as something that you need to pre-cook somehow, and then pass to your vexPOP (as per-particle attributes).... let me think about it some more (I'll be more careful this time )

Cheers!

[edward]

Mario, I'm not quite sure what you mean. An RFE exists already for the ability of the Add Attribute VOP to add a custom variable mapping. For the other attributes in POPs, yeah it would be handy. As you note already, it's not that hard to make your own variable mappings using an AttribCreate SOP on an existing attribute. What I do is use an AttribCreate on an existing attribute and set the values to a point() expression on its iput.

[Mario Marengo]

Hey Jens,

Here's a version that works.... I *think*.... but I'm not making any promises because I think my brain has "vacated the premises" this weekend

Mario, I'm not quite sure what you mean. An RFE exists already for the ability of the Add Attribute VOP to add a custom variable mapping. For the other attributes in POPs, yeah it would be handy. As you note already, it's not that hard to make your own variable mappings using an AttribCreate SOP on an existing attribute. What I do is use an AttribCreate on an existing attribute and set the values to a point() expression on its iput.

Hey Edward; I'm not making much sense today (so maybe I should shut up ), but what I meant was to add the ability from within a vex OP to map existing or custom attributes (where by "existing" I mean incoming, and by "custom" I mean defined locally inside the vex op itself) to "local variable names" that can be used in expressions within the parameters to the vexOP itself (not just further down the stream). It smells a little bit like recursion, but the Attribute POP, for example, already has this functionality (i.e: you can put an expression that uses $AGE in the "Value" parameter, and the expression gets evaluated once per point). Does that make more sense?

Cheers!

duna2.zip

[TheDunadan]

Thanks a bunch edward and mario

Now I have three solutions of my initial problem and I believe I have as well some better understanding concerning the data flow in Houdini now.